Re: [lwip-devel] netifapi limitations

[Joel Cunningham]

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

Joel