[En-Nut-Discussion] En-Nut-Discussion Digest, Vol 73, Issue 24

[Rich Peters]

Ole,

thanks for the comments.  I use Araxis Merge for differences, it has a
unified output report that I will compare that against the diff command
line.
Otherwise I can get the mingw diff.

1. I agree.  Thanks for the recommendation.  I will implement the
solution that way.
3. For number 3,  I thought a better solution would be to have a
parameter on the call that controls the behavior.  I just wanted to get
some feedback about this issue.

thanks
Rich

>
> Thanks for your help! This is very much appreciated. Any patched are
> welcome. And even if not every patch will be applied it gives us at
> least new ideas. 
>
> First a little notice: Could you please use 
>
> diff -ubBdN old-file new-file
>
> to generate your next patches? This will give you more readable unified
> patches.
>
> For now I just reviewed your first patch. And have some comments...
>
>   
>>     1.  fix to nut\crt\write.c to guarantee serialized access to the
>> write used in fputs.c.  this prevents multiple threads from interleaving
>> characters
>>     
>
> I think you try to fix a problem at the wrong place here... Not fputs is
> the problem, but the way it is used. The right way would be to definde a
> mutex for every ressource (filedescriptor in this case) that is used
> from different threads at the same time. You must lock it before calling
> a read / write operation and release it whenever you send out the
> complete data (-set).
>
> This allows you to use other file operations too and even to send out a
> block of data using different i/o operations like fputs, fprintf, fwrite
> and so on in a sequence.
>
> The second problem I see with your patch is the way you test if the
> write is locked or not globaly. This prevents any other thread from
> writing at the same time even to another ressource.
>
> At least you shoule better use the NutEvent API or Mutexes (wich are
> implemented using the NutEvent api) instead of defining a global
> variable and do more or less busy looping with a NutThreadYield.
>
>   
>>     2.  fix to \nut\pro\dhcpc.c - modification to DHCP client code so
>> you can switch between DHCP and static IP addresses without
>> resetting/power cycling.
>>     
>
> This one I'd like to pass over to Harald who better knows the DHCP code.
>
>   
>>     3.  fix to nut\net\ifconfig.c - modification so NutNetIfSetup()
>> doesn't save settings to the EEPROM.  This was using up the available
>> memory writes for the eeprom part since it happens each time the unit
>> powers up.  Code was added to the application to determine when the
>> network information should be saved in the EEPROM.  This might impact
>> compatibility, so maybe this needs to be implemented as a parameter to
>> this function.
>>     
>
> This might be a good idea, but we should discuss it further as it might
> have impacts to the general behaviour.
>
> Bye,
>
> Ole
>
>