Experimental Physics and
Industrial Control System

Vijay Kumar Banerjee via Core-talk <core-talk at aps.anl.gov> · Mon, 8 Mar 2021 18:36:25 -0700

On Mon, Mar 8, 2021 at 3:50 PM Chris Johns <chrisj at rtems.org> wrote:
>
> Hi,
>
> I am sorry if I am a little late to this discussion.
>
> On 4/3/21 9:07 am, Vijay Kumar Banerjee via Core-talk wrote:
> > Hello Michael,
> >
> > On Wed, Mar 3, 2021 at 1:50 PM Michael Davidsaver <mdavidsaver at gmail.com> wrote:
> >>
> >> On 3/1/21 2:43 PM, Vijay Kumar Banerjee via Core-talk wrote:
> >>> Hello all,
> >>>
> >>> In RTEMS 6, there will be no cpukit/libnetworking in the RTEMS
> >>> repository and it will be moved to its own separate repository. There
> >>> are ongoing efforts in this direction and it is very close to
> >>> completion. What's remaining, is to collect feedback from the users of
> >>> the libnetworking stack.
> >>
> >> How will this change be reflected through the rtems-source-builder script?
> >>
> >> My current recipe for building with the legacy stack is eg.:
> >>
> >>> ../source-builder/sb-set-builder --prefix=/opt/rtems/5 --log build.log \
> >>>   --host=powerpc-rtems5 --target=powerpc-rtems5 \
> >>>   --with-rtems-bsp=mvme3100 --with-rtems-legacy-network 5/rtems-kernel
> >>
> > For this, my solution is that I have planned to work on the rtems
> > source builder script and add a recipe for building the legacy stack.
> > This means that if you have scripts that run the source-builder
> > commands, they'll need to be updated to add another line for building
> > the legacy stack. I can explore the possibility of triggering the
> > legacy stack build recipe with an option like
> > --whith-rtems-legacy-network. That might need no or fewer changes in
> > your build scripts, but I'm not sure about how that'll turn out.
>
> 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.
>
> >> Also, is this going the effect our current strategy of using the
> >> RTEMS_HAS_NETWORKING macro?  Or, can you suggest another way to
> >> programmatically identify which network stack is present?
> >>
> > This is an interesting question and I don't have a very straight
> > answer. The RTEMS_HAS_NETWORKING option will be removed along with the
> > relocation patches and it will not be. A not-so-clean solution that I
> > can think of is to add a check in the legacy-net stack waf, so that it
> > builds only when there's no libbsd present. Doing this from the RTEMS
> > won't be very clean as RTEMS needs to be built before any networking
> > stack.
> >
> > Another solution that I can think of is to add a common config file in
> > the build directory, which gets overwritten by whichever network stack
> > is built. So if libbsd is built, it'll overwrite the file to indicate
> > that libbsd stack is present. This can be clubbed together with a
> > warning from waf.
> >
> > Thoughts/suggestions?
>
> 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.
>
The net-legacy produces libnetworking.a, libtelnetd.a, libpppd.a, and libnfs.a
> Chris

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System