Experimental Physics and
Industrial Control System

Vijay Kumar Banerjee via Core-talk <core-talk at aps.anl.gov> · Wed, 3 Mar 2021 15:07:16 -0700

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.
>
> 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?

Best regards,
Vijay
>
> > The legacy repo, in its current state, has been tested with pc-qemu
> > and it can successfully run the legacy networking tests.
> >
> > The following are the links to the repositories with the latest
> > version of changes:
> > RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> > Legacy Network: https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
> >
> > The following BSP family in RTEMS has been used with the old legacy
> > networking stack:
> > Zynq, PC, Motorola Shared, Beatnik, mvme3100, mvme5500, gen68360,
> > uc5282, mvme 162/167
> >
> > If anyone is maintaining/working with one (or more) of these BSPs,
> > please let me know if you're able to test the separate legacy-net
> > repository and if you have any feedback. If you're planning to test
> > it, please add your comments here so that we know someone is going to
> > do it and wait for your feedback. The changes will not be pushed right
> > away and we'll follow-up for your feedback.
> >
> > What's next?
> >
> > The legacy networking repository will stay at git.rtems.org for any
> > projects that are still using it. It is recommended that the new
> > projects use the libbsd networking stack which is more full-featured.
> > There is a strong possibility that we will add lwip next, but no
> > timeline has been decided for it yet. We plan to provide a performance
> > analysis of lwip and libbsd networking (and maybe legacy networking as
> > well)
> >
> > Thank you for your patient reading. Any suggestion is welcome and I'm
> > more than happy to work with you to get it more thoroughly tested.
> >
> > Best regards,
> > Vijay
> >
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System