RE : RE : [lwip-users] Callbacks

[Frédéric BERNON]

>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.

No, inside the status callback, to know the state, you can call netif_is_up() 
(and netif_is_link_up for the other callback).

 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Nicolas Pinault
Envoyé : mardi 2 octobre 2007 16:01
À : Mailing list for lwIP users
Objet : Re: RE : [lwip-users] Callbacks



> 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



_______________________________________________
lwip-users mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf