Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository

[Chris Johns]

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

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.

Chris