On Wed, Mar 3, 2021 at 5:46 PM Chris Johns <chr...@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 <j...@rtems.org> wrote: > >> > >> On Wed, Mar 3, 2021, 2:49 PM Heinz Junkes <jun...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
