[Top][All Lists]

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

Re: [lwip-devel] netifapi limitations

From: Sylvain Rochet
Subject: Re: [lwip-devel] netifapi limitations
Date: Mon, 19 Mar 2018 12:19:18 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

Hi Jonathan,

On Sat, Mar 17, 2018 at 03:43:35PM +0000, Jonathan Larmour wrote:
> On 16/03/18 10:46, Sylvain Rochet wrote:
> > 
> > Since netif struct is not allocated/freed by the stack itself, how is 
> > getting a netif pointer a problem at all ?
> You can't safely modify the netif list using netif_add()/netif_remove()
> outside of the tcpip thread context, and they would probably only be
> added/removed by driver code anyway, in which case it would be in the tcpip
> thread context.
> If you're saying that it's okay to have a big layer violation between
> application and net driver, then while obviously lwIP is all about layer
> violations for efficiency :-), at the same time it does make it harder to
> write reusable and portable higher layer code, which is one of the biggest
> motivations for the existence of the netifapi really.

Well, I guess I just don't understand the issue here. For me netifapi is 
just a wrapper to call netif_* functions inside the tcpip core thread. 
(e.g. netifapi_netif_add() and netifapi_netif_remove() to call, 
respectively, netif_add() and netif_remove() inside the tcpip thread.)

Other than that, netif struct allocation is done by application code so 
using it in the netif/netifapi APIs should not be an issue, lwIP itself 
is never going to change netif references. This is even true for PPP, 
application code have to provide its own netif struct to ppp_new().


Attachment: signature.asc
Description: Digital signature

reply via email to

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