Re: ANN: RTEMS libnetworking relocation

[Chris Johns via Core-talk <core-talk at aps.anl.gov>]

On 9/3/21 2:16 pm, Johnson, Andrew N. wrote:
> On Mar 8, 2021, at 4:49 PM, Chris Johns via Core-talk <core-talk at aps.anl.gov
> <mailto:core-talk at aps.anl.gov>> wrote:
>>
>> The stacks are considered separate packages and I hope they can be built
>> independently and installed side by side under the BSP. From an RTEMS
>> perspective if a stack (or any 3rd party package) can be built I would prefer
>> that happens so users can select which ever stack they want using options or
>> configurations they have control over.
> 
> Isn’t there an overlap between the header files that come with the two stacks?
> If you want to be able to install both stacks, they probably need to install
> their headers into different places.
> 
> I recently rebuilt a BSP to change from the libbsd stack to the legacy one,
> installing the result into the same prefix. I didn’t delete the old BSP tree
> first, and the result was a mixture of headers in the BSP’s lib/include
> directory. The EPICS code was still pulling in a header from the libbsd stack
> that it shouldn’t have been using, and the result was a linker error with
> missing symbols for some shell commands that are not present in the legacy
> stack. It wasn’t until I rebuilt the BSP from scratch that I found the wrong
> header issue in our code.

In theory there should not be a clash of headers for the user facing files.
Sebastian at Embedded Brains has been moving a number of networking headers into
newlib (lib[cm]) so the vertical stack dependency can be avoided. I however do
not know the final out come of the removal of libnetworking from the rtems.git
repo. There may be some overlaps and I can take this question away to be looked
into. As you correctly observe it is important this does not happen. There are
headers that are specific to the legacy stack and do not clash that will be
present and this may require changes in your code to not include them. I cannot
see a way we can avoid this.

>> Can the EPICS build system check the BSP to see which libraries are present and
>> then decide which stack to use? The libbsd library is libbsd.a and I am not sure
>> what the net-legacy archive name is.
> 
> How do you reconcile those two: If both stacks can be built for a BSP, both sets
> of libraries would be present, so checking for the presence of one or the other
> library wouldn’t tell us which to use.

This is something we (the RTEMS project) cannot decide on for all users. A user
may want to transition over a period of time where they run RTEMS 5 with the
legacy stack while they test RTEMS 6 with the legacy and libbsd stacks.

We encourage users to switch to libbsd but we also understand some users and
systems may never move off the legacy stack for reasons that are specific to
their site and systems.

The legacy stack in rtems.git had become a distraction because it looked like
RTEMS only supported 20 year old networking functionality. We have welcomed the
change to move it into a separate repo and to have it built as a package because
it will be available for those who want to continue using it.

We are working hard in RTEMS to bring all the 3rd party packages needed by EPICS
closer to the RTEMS project so we can make sure they build and if possible
tested as part of our development work flow. We hope this will aid EPICS in
moving between releases of RTEMS. The 3rd party packages do not define a BSP,
they are additional and so I am not sure how we can include them in the BSP
configuration data that is created before these packages are built. I do not see
updating configuration information generated lower down in the software stack as
an option because it steps on the configuration management aspects of
configuration control.

> We don’t currently have a way in EPICS to adjust what we build based on what
> libraries are available upstream, although that could be added if necessary. The
> user needs to specify that kind of thing somewhere, but I think we’d prefer that
> the RTEMS BSP tell us how it has been configured in the makefile fragments that
> we include from the BSP. If the user has to provide information about how the
> RTEMS BSP was built in their EPICS build configuration but they get it wrong our
> code will fail to build, so it seems more sensible for our build system to get
> as much information as it can directly from your build system.

It is fine if EPICS does not support configure tests. EPICS providing a fixed
configuration for a BSP that has been tested and approved for use makes sense to me.

I appreciate your wish for the BSP to tell you what to use however our hope is
both stacks build and work where possible so we cannot say which is best for you
and your users. For some BSPs there is no choice and others there is. Fixing the
selection in EPCIS is a good solution.

While discussing RTEMS supplied option settings we are looking to make other
changes. The POSIX option is changing in RTEMS 6. It use to mean the POSIX API
is enable and for RTEMS 6 POSIX is always enabled. The smart initialisation in
RTEMS manages the resources so there is no need to control the POSIX API when
building RTEMS. The configure option is still called POSIX however it now only
controls POSIX signals.

> If you get to the stage were a user can have both stacks built and installed so
> that switching between them would just be a matter of user preference when EPICS
> gets built, then letting the user choose the stack in their EPICS target
> configuration would be fine, but we’d want to be able to confirm that their
> RTEMS build actually contains the stack they’re asking for at the start of our
> build, not when we first try to compile or link an application image against it.

Can EPICS check the BSP for a library level? For example something similar to a
check a BSP is installed?

Chris