Re: [lwip-devel] netifapi limitations

[Jonathan Larmour]

On 19/03/18 22:07, Joel Cunningham wrote:
> On 03/17/2018 11:16 AM, Jonathan Larmour wrote:
>> On 16/03/18 13:48, Joel Cunningham wrote:
>>> On 03/15/2018 09:23 PM, Jonathan Larmour wrote:
>> It's exactly the sort of thing netifapi should be able to do though, maybe 
>> not
>> immediately, but having the right sort of API for the future.
> I agree we should have APIs that do this, but I don't have strong feelings
> that it should be netifapi. I will eventually want to implement things at the
> socket levels so I can re-enable interface code in some common OSS
> applications that I've currently had to disable (use of getifaddrs for 
> example).

Having variants which take interfaces would help here, as per my reply to 
Sylvain.

>> I assume it's
>> https://savannah.nongnu.org/task/?func=detailitem&item_id=14314#comment45 in
>> particular. I think the lwIP philosophy in general is make the "native"
>> interface be simple and low overhead. Anything that wants to add a
>> standards-compliant veneer that would add overheads should be the place for
>> taking a hit in space/efficiency.
>>
>> So that implies to me we should either have a netifapi function as an 
>> iterator
>> (my preference - lower memory and doesn't need dynamic mem alloc), or a
>> function parallel to if_nameindex() but using netif types. The if_nameindex()
>> veneer would use the underlying netifapi, but entail a bit more overhead. 
>> This
>> fits with the lwIP philosophy in my mind.
> The problem with an iterator is the inherent race in trying to iterate while
> leaving the LwIP core for each iteration. A netif_add/remove could happen
> during an iteration and cause a bunch of nasty cases.

Yes, you're right.

> I'm more in fan of a
> single call that returns an atomic snapshot of the interfaces at the time of
> the call, but this requires a dynamic memory allocation within netifapi

An alternative is that we require the caller pass in an array of (index,name)
tuples, along with the number of entries in that array. This covers well the
scenario that the caller will probably know exactly how big to make that array
anyway; and if they don't know exactly, it's up to them not lwIP to decide
what they consider the maximum. A return code could indicate if there were
more netif's than would fit. Each name member would be IF_NAMESIZE bytes
(currently 6).

An implementation of if_nameindex() could easily wrap this by dynamically
allocating that array and passing in the size-1 to allow for the final entry
needing to be (0,NULL).

>> [1] Although existing practice on UNIX-y systems shows that having a naming
>> convention for names can be useful in practice, even if only a prefix, not a
>> number.
> I need to spin up more on naming under Linux, but I've seen kernel features
> for different kinds of names depending on the driver, i.e. predictable vs
> unpredictable naming. At least on my Ubuntu 17.10 box, it's renaming the
> devices to have long numbers, appears to be based off MAC:
> 
> $ ifconfig -a
> 
> wlx6466b31999f5: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
>         ether 64:66:b3:19:99:f5  txqueuelen 1000  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 0  bytes 0 (0.0 B)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Long suffix yes, but looks from the prefix that it's a Broadcom wireless lan
(wl) driver :-). More relevant is that Linux knows the device class is
Ethernet, but I'd rather not have that in lwIP as it would just take up space
permanently in a netif for something few users would need.

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