[lwip-devel] [bug #20409] Add netif callback function for link change event

[Jared Grubb]

Follow-up Comment #34, bug #20409 (project lwip):

> manually up/down a netif is a basic operation on lwIP. Any embedded
application can decide to down its netif if it want to "stop" any services
activity...

If we give the user "master" powers over a netif, then he expects the stack
to obey them. The stack should not call those same functions that the user
has -- DHCP should not call netif_set_up if that's the function we tell the
user he can use. Otherwise, we could have the user call netif_set_down only
to find that DHCP called netif_set_up() all on its own later on because it
wasnt stopped.

Let's talk about how the user and driver could interact with the stack in an
ideal world, as though the stack is a big black box:

Let's emulate Linux. The user calls netif_set_up() and netif_set_down() which
has global enabling and disabling powers. Inside of that, the user can call
whatever IP acquisition he chooses; netif_set_down() is smart enough to call
any *_stop() functions that are appropriate. For example:

netif_add();
netif_set_up();
dhcp_start();
dhcp_renew();
dhcp_stop();
autoip_start();
/* let's say this next line happens somewhere else in code that doesn't know
what IP acquisition we used */
netif_set_down(); 
// user forgot (or didnt know he had to do) autoip_stop()
// that's ok, the stack will do it for him

So, we define states just like in Linux
* UP and DOWN are completely controlled by the user. 
* LINK and NO LINK are completely controlled by the driver. 
* RUNNING and NOT RUNNING are completely controlled by the stack.

We have an entry point for the driver for link change:
* netif_link_change(), called whenever the link changes.

We have the following callbacks (both optional via lwipopts) defined in the
netif:
* application_status_callback to the application in response to changes in
RUNNING/NOT RUNNING; for example, IP address acquisition
* driver_status_callback to the driver in response to UP/DOWN; for example, a
down driver can turn off its circuits (but stay initialized)

This only defines how the USER and DRIVER interact with the stack, but does
not define how the stack actually implements these behaviors. In my world,
this would be my ideal way to interact with the stack. What do you think?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?20409>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/