lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE : [lwip-users] Callbacks


From: Nicolas Pinault
Subject: Re: RE : [lwip-users] Callbacks
Date: Tue, 02 Oct 2007 16:00:34 +0200
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)


Both integration are different :

- for status callbacks, most of the job is already done. I have to set LWIP_NETIF_STATUS_CALLBACK=1 in your 
lwipopts.h. In your "ethernetif_init" call netif_set_status_callback(...) to provide a 
status_callback for your netif. Implement your status_callback. Since the only parameter this callback got is 
the netif*, you can call netif_is_up to know if the netif is up or down. Don't forget this callback is most 
of time running in the "core" context (the tcpip_thread by example). So, don't do a long processing 
in this callback (because you "block" all other processing - input packets processing, api 
calls...).

Some code snippet for status handling:

err_t
ethernetif_init(struct netif *netif)
{
  ...
  netif_set_status_callback( netif, myapp_status_change_handler); <<<<<< HERE, your 
"application level" callback
  ...
}
That's what I do. The only point is that I thought there is some sort of "status message" to use in the callback. Obviously, this is not the case.

- for link status, a part of the job is done, but not the "event" part: you have to LWIP_NETIF_LINK_CALLBACK=1 in your lwipopts.h, and call netif_set_link_up() and 
netif_set_link_down() when your link change of state. You can poll that with a thread or perhaps use an interrupt and an event. Since the "netif_set_link_up" calls 
"core" functions (to send a "gratuitous ARP" and/or resend IGMP reports), it could be better to do that in the "core" context. So, like for 
"status", don't do a long processing in this callback. I think the best is to use a tcpip_callback() or a tcpip_timeout() call to "switch" in the tcpip_thread 
context. tcpip_callback() can be used if there is no delay between the time where the link "up", and the time where you can send packets. If there is a delay, 
tcpip_timeout() can be better. Note it's not mandatory to call netif_set_link_callback() if you don't want inform your "application level", but just want to do 
"link up" processings.

Some code snippet for link state:

err_t
ethernetif_init(struct netif *netif)
{
  ...
  netif_set_link_callback( netif, myapp_link_change_handler); <<<<<< HERE, your 
"application level" callback
  ...
}

...

void
ethernetif_interrupt_or_event() <<<<<< HERE, any "context" which see the link 
state change
{
  ...
  /* check the link current state */
  if (my_driver_is_link_up_variable_name) {
    /* Process the link change in tcpip_thread context in 1sec */
    tcpip_timeout(1000, netif_set_link_up, (void*)netif);
  } else {
    /* Process the link change in tcpip_thread context asap */
    tcpip_callback(netif_set_link_down, (void*)netif);
  }
  ...
}
Very good explanation. I missed the context execution problem for netif_set_link_up and netif_set_link_down.

Thank you very much for your support.

Nicolas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]