Re: ANN: RTEMS libnetworking relocation

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

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


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?


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