Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository
Vijay Kumar Banerjee
vijay at rtems.org
Thu Mar 4 01:52:46 UTC 2021
On Wed, Mar 3, 2021 at 5:46 PM Chris Johns <chrisj at rtems.org> wrote:
> 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.
> 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.
More information about the devel