[Top][All Lists]

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

Re: [lwip-devel] netifapi limitations

From: Joel Cunningham
Subject: Re: [lwip-devel] netifapi limitations
Date: Mon, 19 Mar 2018 16:47:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/19/2018 06:19 AM, Sylvain Rochet wrote:
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.)
I kind of feel the same way that netifapi is just the netif API that can be used outside the LwIP core context.  The level of APIs I'm looking for (and I think is the same for Jonathan) largely don't exist except if_nametoindex and if_indextoname.

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().
I also agree here that code allocating the netif struct is what should be using netifap/netif, but that is also not the same level of code we've been discussing.

I've got a number of applications that use the sockets interface which need things like getifaddrs/ioctl(...SIOCGIFCONF) which I've had to write custom code which is effectively grabbing the core lock, then iterating the netif list and returning configuration. The application code doesn't do anything with LwIP's struct netif, nor would it have a way to since the code managing struct netif is in a completely different part of the system (what I refer to as link layer management code).


reply via email to

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