Re: [lwip-devel] netifapi limitations

[Jonathan Larmour]

[ Gah, stupid Enigmail managed to muck up the formatting of the reply to
Sylvain, as well as sending a mail prematurely. Sorry about the previous 
junk...]

Thanks for the reply Joel.

On 16/03/18 13:48, Joel Cunningham wrote:
> 
> On 03/15/2018 09:23 PM, Jonathan Larmour wrote:
>> I've noticed a limitation in the netifapi (not the netif API!) : [snip]
>
> This is definitely a limitation that has been discussed before on the list
> (see https://savannah.nongnu.org/task/index.php?14724). To me, the netif and
> netifapis are really only useful from code that manages a struct netif (owns
> the allocation/reference, so it can safely pass pointers). I think of this as
> link layer management code, which typically adds/removes the neift, applies
> configuration settings and not network application code that lives above the
> stack.

But it's not potentially just application code but higher layer protocol code.
Think of something like mDNS, which ought to sit on top of lwIP, but would
need access to data which at the moment is only accessible in a netif.

Now, I'm not intending at this point to provide an all-singing all-dancing
abstraction and API to do that, but it would be good to be making steps in the
right direction and at the moment having the netifapi take 'struct netif *'
seems like it would store up problems for the future, in which case it's
better to address it sooner and switch to an index before things become too
hard to change.

> I think for network application code, additional APIs are needed to get things
> like get address information, list of interfaces.  LwIP doesn't have any of
> the normal things like getifaddrs and in my projects, I've got custom code to
> do these lookups in a safe way.

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.

> We made some progress implementing ifnametoindex/ifindextoname, but
> encountered some implementation issues with if_nameindex (which enumerates all
> interfaces).  See 
> https://savannah.nongnu.org/task/?func=detailitem&item_id=14314

Thanks, I hadn't seen that.

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.

>> 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:
> Given how it's implemented on git master with the index, you're right the
> resulting name is non-deterministic. If we had something like
> getifaddrs/if_nameindex, we could enumerate the names, but I think having
> names which can be hardcoded into applications isn't a good practice.

I'm not sure it's about hardcoding names necessarily[1], but being able to
find information about all available netif's, whatever they are. The current
situation is worse than a hardcoded name though - you need a hard-coded
reference to a specific netif structure.

Jifl

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