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

[Joel Sherrill]

On Tue, Apr 20, 2021 at 7:07 PM Chris Johns <chrisj at rtems.org> wrote:

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

This is a linker script section attached to some variables in a very
specific
LWIP driver. The special memory  section should have an equivalent in the
standard RTEMS linkcmds.

How about an ifdef rtems in the driver to adapt to the BSP's linkcmds?

--joel

>
> Chris
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210420/059a4d02/attachment-0001.html>