[En-Nut-Discussion] temporary hack in the thread NicRx

[Harald Kipp]

>
>   /*
>    * This is a temporary hack. Due to a change in initialization,
>    * we may not have got a MAC address yet. Wait until one has been
>    * set.
>    */
>
>I couldn't recognize what case enables NicRx() thread before the MAC
>is set.

Two changes are responsible:

1. Device initialization had been called during DevOpen/NetConfig.
This was bad for Harddisk support and it's also more logical to
detect a device init failure earlier. So device initialization
is now done when NutRegisterDevice() is called.

2. If the EEPROM doesn't contain a valid network configuration,
the "default" MAC address egnite-00-00-00 has been used. Since
version 3.2 there's no such thing as a default MAC. It's up to
the application to either
   a) Make sure that the EEPROM is valid.
or
   b) Deliver the MAC address when calling NutDhcpIfConfig()
      or NutNetIfConfig()

NutDhcpIfConfig() is new and additionally supports DHCP timeout.
It offers some added flexibility to the application code,
for example:

     /*
      * LAN configuration using EEPROM values or DHCP/ARP method.
      * If it fails, use fixed values.
      */
     if(NutDhcpIfConfig("eth0", 0, 60000)) {
         u_char mac[] = { 0x00,0x06,0x98,0x00,0x00,0x00 };
         u_long ip_addr = inet_addr("192.168.192.100");
         u_long ip_mask = inet_addr("255.255.255.0");

         puts("EEPROM/DHCP/ARP config failed");
         NutNetIfConfig("eth0", mac, ip_addr, ip_mask);
     }

Why is it temporary? I'd like to remove NutNetAutoConfig, but
not too soon to avoid breaking too many existing apps. More important,
the current solution is unsafe, because it depends on async timing.
After starting NicRx, it is assumed, that this thread reaches the
wait-for-mac-loop before NutDhcpIfConfig() sets the MAC address.
Otherwise the controller will never get initialized.

Final solution would be to split the initialization into two parts.

I) NutRegisterDevice() resets the Ethernet controller and does
a basic hardware check and configuration.

II) NutDhcpIfConfig() / NutNetIfConfig() will set the MAC address and
fire up the controller.

This will require a few changes in the driver code and I'd like to
finish the LAN91C111 driver first before making further decisions.

>   Also, I have little concern about the fact 00:00:00:xx:xx:xx might
>be a valid MAC address which is associated to XEROX.
>
>   Using FF:FF:FF:FF:FF:FF as a mark might be better, I think.  Since
>it indicates a broadcast MAC address, and is never associated to any
>network controller.  Or, inserting a flag in IFNET structure is well
>too.

I doubt that we will ever see 00:00:00 anywhere, but I agree. Using
FFs is a far better value.

Harald