network configuration was: [PATCH 4/4] RTEMS_USE_LWIP option to use lwip in RTEMS

[Chris Johns]

On 21/4/21 3:37 am, Gedare Bloom wrote:
> To me, it doesn't make any sense that someone will build and install
> RTEMS with multiple networking stacks for the same application. 

I do this. I have applications in production with the legacy stack and being
tested and developed against libbsd. This may continue for a while.

> The
> only exception I might think is some middleware like EPICS. But even
> if they do, probably they need some way to partition the stacks, and
> we currently don't have a clean separation of the stacks, i.e., there
> can be header file name clashes if you tried to install two different
> stacks to the same prefix.

The applications I have are built against separate RTEMS trees as this work is
still before the separation and with those builds it knows if the legacy stack
is present via the opt files. With the separated stacks I would like to move to
a single build of RTEMS and all the networking stacks and the application is
built against a common RTEMS and each stacks. The makes the configuration
management simpler.

> I think it makes sense to only allow one networking stack installed to
> a prefix. 

This is a sensible place to start but I would like to move to a single prefix.

> If making that selection is easier/consistent to do at RTEMS
> configuration time, then I think we should consider it. 

I prefer we do not, we are looking to separate the stacks and not almost
separate them :)

Having said this it may not be possible to have a clean separation right now
but I think this is what we should aim for. The counter position is more links
such as this one are added cause it is easy and overtime that results in more
complexity in how we combine and test everything.

> Then the
> networking stack repo(s) can pluck the configuration variable from the
> installed RTEMS, and complain if RTEMS was not configured for that
> network stack.

I have not looked at the technical level what the specific issue is but I ask if
another way can be found. It may be a little more work upfront but if we can
always build the LwIP specific code it will be naturally maintained. How that is
pulled into a LwIP application is the challenge.

> This will obviate any need for BSP-specific configuration variables
> for networking stacks, they can just inherit from the top-level config
> option.

Configuring anything for a post RTEMS dependent build will end in tears. I
prefer we discourage this. RTEMS configurations should be about RTEMS.

I acknowledge there is a fine line here between RTEMS_LWIP and
STM32H7_ENABLE_LWIP_SUPPORT or STM32H7_ENABLE_NET_XZY_SUPPORT. I prefer specific
functions or drivers are created that are always built and then selected the stack.

Chris