Experimental Physics and
Industrial Control System

Vijay Kumar Banerjee via Core-talk <core-talk at aps.anl.gov> · Wed, 3 Mar 2021 18:52:46 -0700

On Wed, Mar 3, 2021 at 5:46 PM Chris Johns <chrisj at rtems.org> wrote:
>
> Hi,
>
> Well done on the hardware testing.
>
> On 4/3/21 9:15 am, Vijay Kumar Banerjee wrote:
> > On Wed, Mar 3, 2021 at 2:32 PM Joel Sherrill <joel at rtems.org> wrote:
> >>
> >> On Wed, Mar 3, 2021, 2:49 PM Heinz Junkes <junkes at fhi-berlin.mpg.de> wrote:
> >>>
> >>> Hallo Vijay,
> >>> I still have to ask a question ;-)
> >>>
> >>> When building EPICS, we distinguish legacy stack or libbsd with the help of
> >>> the target.cfg file. (e.g. powerpc-rtems6/beatnik/make/target.cfg).
> >>>
> >>> Earlier in it was
> >>> RTEMS_HAS_NETWORKING = yes (for legacy stack) and no (for new bsd stack).
> >>>
> >>> Now  this flag will no be set with the waf build in your extra net-legacy repo.
> >>>
> >>> How should we now find out if the target was built with legacyStack or with libbsd?
> >>
> >> Eventually RTEMS itself won't have this at all. It will always have no networking and you have to add a stack.
> >>
> >> This may be something that needs addressing. Not sure.
> >
> > I got the same question for Michael on the core mailing list and I
> > have added a note there that I am planning to add an RSB recipe that
> > will make it easier to build the legacy networking stack.
>
> Excellent and thanks.
>
> > Regarding the macro: I am not sure which path is "cleaner", but I can
> > think of two possible solutions. One is to add a common config file
> > that gets written by the libnetworking stack that will indicate that
> > legacy networking is used. This might also mean that we can actually
> > overwrite the target.cfg itself to indicate it.
>
> I am not sure this works because there maybe more than one stack installed at
> the same time. I saw the selection and management as something a user handles
> like any other 3rd party package. They use their build system to test and detect
> what is installed, eg a link test for a library. If there are more than one they
> need to resolve the selection.
>
> > I have written a detailed post here as well:
> > https://epics.anl.gov/core-talk/2021/msg00382.php
>
> The RSB networking options when building the kernel will be made to generate an
> error so users know there is no support any more.
>
> The path I see is:
>
> 1. Add a package to the RSB to build net-legacy (similar to libbsd)
>
> 2. Add the net-legacy package to the default stack of packages built
>
> 2. Add BSPs like the one for Heinz to the list of available BSPs the RSB can build
>
Thanks for this defined set of paths, the idea is clear to me now.

> This results in 2 installed networking libraries and the selection is in the
> domain of the user and their build system. Users who support both stacks will
> need to build and include the correct initialisation and driver support.
>
Ah, Ok.

> There should be no need for a user to rebuild RTEMS to select the legacy or
> libbsd stacks.
>
> We should encourage users to add BSP build stacks to the RSB. I remember Andrew
> Johnson posted on for a Coldfire. We should merge that one.
>
> Chris

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System