<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 20, 2021 at 7:07 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 21/4/21 3:37 am, Gedare Bloom wrote:<br>
> To me, it doesn't make any sense that someone will build and install<br>
> RTEMS with multiple networking stacks for the same application. <br>
<br>
I do this. I have applications in production with the legacy stack and being<br>
tested and developed against libbsd. This may continue for a while.<br>
<br>
> The<br>
> only exception I might think is some middleware like EPICS. But even<br>
> if they do, probably they need some way to partition the stacks, and<br>
> we currently don't have a clean separation of the stacks, i.e., there<br>
> can be header file name clashes if you tried to install two different<br>
> stacks to the same prefix.<br>
<br>
The applications I have are built against separate RTEMS trees as this work is<br>
still before the separation and with those builds it knows if the legacy stack<br>
is present via the opt files. With the separated stacks I would like to move to<br>
a single build of RTEMS and all the networking stacks and the application is<br>
built against a common RTEMS and each stacks. The makes the configuration<br>
management simpler.<br>
<br>
> I think it makes sense to only allow one networking stack installed to<br>
> a prefix. <br>
<br>
This is a sensible place to start but I would like to move to a single prefix.<br>
<br>
> If making that selection is easier/consistent to do at RTEMS<br>
> configuration time, then I think we should consider it. <br>
<br>
I prefer we do not, we are looking to separate the stacks and not almost<br>
separate them :)<br>
<br>
Having said this it may not be possible to have a clean separation right now<br>
but I think this is what we should aim for. The counter position is more links<br>
such as this one are added cause it is easy and overtime that results in more<br>
complexity in how we combine and test everything.<br>
<br>
> Then the<br>
> networking stack repo(s) can pluck the configuration variable from the<br>
> installed RTEMS, and complain if RTEMS was not configured for that<br>
> network stack.<br>
<br>
I have not looked at the technical level what the specific issue is but I ask if<br>
another way can be found. It may be a little more work upfront but if we can<br>
always build the LwIP specific code it will be naturally maintained. How that is<br>
pulled into a LwIP application is the challenge.<br>
<br>
> This will obviate any need for BSP-specific configuration variables<br>
> for networking stacks, they can just inherit from the top-level config<br>
> option.<br>
<br>
Configuring anything for a post RTEMS dependent build will end in tears. I<br>
prefer we discourage this. RTEMS configurations should be about RTEMS.<br>
<br>
I acknowledge there is a fine line here between RTEMS_LWIP and<br>
STM32H7_ENABLE_LWIP_SUPPORT or STM32H7_ENABLE_NET_XZY_SUPPORT. I prefer specific<br>
functions or drivers are created that are always built and then selected the stack.<br></blockquote><div><br></div><div>This is a linker script section attached to some variables in a very specific </div><div>LWIP driver. The special memory  section should have an equivalent in the</div><div>standard RTEMS linkcmds.</div><div><br></div><div>How about an ifdef rtems in the driver to adapt to the BSP's linkcmds?</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>