Re: [lwip-devel] netifapi limitations

[Jonathan Larmour]

Hi Sylvain,

On 16/03/18 10:46, Sylvain Rochet wrote:
> On Fri, Mar 16, 2018 at 02:23:02AM +0000, Jonathan Larmour wrote:
>> I've noticed a limitation in the netifapi (not the netif API!) :
[snip]
>> That brings me to a second issue, netif_find() assumes that the netif 
>> name is exactly three chars long, the third being the if number from 
>> 0-9.
> 
> Which version of lwIP are you using ? It doesn't seem to be the case. 
> http://git.savannah.nongnu.org/cgit/lwip.git/tree/src/core/netif.c?id=6070a7ef6a9c1fd4f9b7d2dd16b412110a466244#n1656

Aah,
>
>
>
>
>
> 
you're right, I'd been looking at the STABLE-2_0_0 branch rather than
head. That's great that there are improvements here.

>> The number is assigned in netif_add() by incrementing a local static 
>> variable each time. [snip]
> 
> We take care of this issue in netif_add() by iterating over the netif 
> list to find a free entry if necessary. 
> http://git.savannah.nongnu.org/cgit/lwip.git/tree/src/core/netif.c?id=6070a7ef6a9c1fd4f9b7d2dd16b412110a466244#n367

Again
>
>
>
>
>
> 
an improvement over 2.x.


[snip]
>> Next, if the numbers are part of the name, but are assigned by lwIP, 
>> how can netif API users even find an interface except in the most 
>> simple static cases, and making assumptions about interface 
>> initialisation order? It makes me think we need an iterator function
>> in netifapi to report the next used index (which in practice just 
>> traverses the netif list). For example:
>> 
[snip]
> 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.

But as Joel pointed out, there have been thoughts about this already in
https://savannah.nongnu.org/task/?func=detailitem&item_id=14314 . I'll reply
to Joel about that.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine