[En-Nut-Discussion] Submit some patches

[Ole Reinhardt]

Hi Rich,

> my first post here...

So welcome to the list :)

> I have inherited a firmware project that was based on ethernut 4.0.1.
> This project contains a number of modifications to the Nut/OS, which I
> dont know if they were ever submitted as patches or not.  I have merged
> the patches with 4.8.5 and tested them. They work well, so I have
> submitted them to sourceforge in the patch area.  

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

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280