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.