Re: [lwip-devel] netifapi limitations

[Jonathan Larmour]

Thanks for replying Sylvain,

On 19/03/18 11:19, Sylvain Rochet wrote:
> On Sat, Mar 17, 2018 at 03:43:35PM +0000, Jonathan Larmour wrote:
>> 
>> 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.)

There are two scenarios I'm thinking of: one is that there isn't always a
strict divide between lwIP on one side and application on the other - there
can be higher level subsystems, modules or protocol implementations, which
sit between lwIP itself and the application. The second is simply code
reusability: someone wants to write code that will work on this product, and
doesn't need magic to be changed to work on the next just because it uses
e.g. a different ethernet driver. Having to build directly in to such code
knowledge of specific netif's would not be good practice.

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

I know you are interpreting "application" as "anything not lwIP", but I'm
trying to say that there is more to it than that :-).

Take as an example: lower level hardware-specific code can bring up one or
possibly many interfaces. This code conceptually sits underneath even lwIP.
But higher layer code (above lwIP) may want to provide a web server with
management interface to allow users of this product to do things like switch
between DHCP or static IP settings on whatever interfaces are available.

Now it is certainly possible for supposedly reusable high level code to
bypass lwIP and have fingers in the low level code in order to access the
netifs - you have the source so anything is possible. But it is poor design
practice and leads to unportable code. And gets complicated when there could
be things like USB ethernet devices which can be plugged and unplugged at
any time. I don't think that is a good thing and instead is the sort of
thing the netifapi should be solving and _can_ solve. lwIP should be acting
as the intermediary between high level code using lwIP and hardware drivers
underneath lwIP.

Another possibility I guess is to retain the existing functions which take
'struct netif*' arguments, but also add variants which take if index
arguments. e.g. netifapi_dhcp_start() and netifapi_dhcp_start_by_index().
[Note, these shouldn't just be wrappers for e.g. netifapi_dhcp_start()
because I would be concerned about netif pointers going stale if a netif did
happen to get removed by code elsewhere at the same time - think USB eth
again]. But it would be easy to tweak struct netifapi_msg to support an
index instead of netif and netifapi_api_common do the right thing with it.

Does this sort of thing sound like a step forward?

Jifl
-- 
------["Si fractum non sit, noli id reficere"]------       Opinions==mine