Standalone repository for libnetworking stack

[Chris Johns]

On 6/2/21 8:28 am, Joel Sherrill wrote:
> On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer <oss at c-mauderer.de
> <mailto:oss at c-mauderer.de>> wrote:
> 
>     Hello Vijay,
> 
>     On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:
>     > Hello,
>     >
>     > I'm currently working on separating the libnetworking stack into its
>     > standalone repository that can be built separately with waf. The current
>     > status of the project is that I have a working rtems-libnetworking
>     > repository [1] that builds with waf (hasn't been tested with any test
>     > cases yet). And In my fork of RTEMS I have separated the libnetworking
>     > stack [2].

If you have not already done so I suggest you create repos in your personal area
on dispatch.rtems.org and these will appear on the cgit page. It is a simple way
to get exposure to the work.

>     Sounds like an interesting work. If I didn't miss an earlier discussion:
>     I think the name might could trigger one. It gives the impression that
>     it is _the_ networking stack to use. But for newer BSPs most of the time
>     libbsd is the better choice.
> 
> 
> We could make it painful and obvious using something like 
> rtems-legacy-networking :) 

.. or rtems-net-legacy ... small, clear and simple.

> I assume you are also taking all legacy network drivers with you.

Yes this is a good point. They will have to move as well. I hope this does not
create links back into BSP specific headers that are not currently being installed.

> One random thought is whether this should only build for specific BSPs. We
> currently can build the stack for nearly all architectures but I don't think that
> realistically there are BSPs which run it on all architectures. Should there be
> a whitelist of supported BSPs?

There are BSPs where the drivers are not in RTEMS because of chip vendor
licensing issues. Why not follow the rtems-libbsd model?

> And I used "supported" quite loosely. I expect that other than a 
> small number of BSPs you can check on simulators, this is not going to
> be heavily tested beyond building. This is not a criticism. I think it is
> just a reality of doing something better than removing it entirely.

If it is tested when split and then maintained so it builds it should stay in a
reasonable state. We just need to state clearly our intentions and if someone
really needs support there are commercial support options.

>     > I need suggestions with the following questions:
>     >
>     > 1. What to do with the codes in RTEMS outside the libnetworking stack,
>     > which uses the networking library. Libraries for example libpppd uses
>     > libnetworking. Do we want to shift these to the separate repository for
>     > libnetworking or do we want to keep them in RTEMS and use the waf system
>     > to selectively built those when the libnetworking is available in
>     > PREFIX. We can add a common header file that #defines RTEMS_NETWORKING,
>     > so that the related codes can be built and used.
> 
>     I think it depends:
> 
>     Can they be used with libbsd or only with the legacy stack?
> 
> I thought the point of having the network headers in newlib was to enable
> user space networking applications that could build independent of the
> network stack in use. I think these should stay in rtems/ as much as possible.

Do we need to audit which pieces are generic networking applications and which
are tied to libnetworking. For example libbsd has an NFS network client and so
does the legacy stack.

>     If they can be used with libbsd: Can they be build without a networking
>     stack? In that case it might would be possible to build them in RTEMS
>     and link them later with either libbsd, with libnetworking or (maybe)
>     some-when with lwIP. I don't think there is a reason to not build them
>     for any BSP if they can be build without a networking stack.
> 
> Yes. This is how it is supposed to work and should with libbsd now. 

This is also my understanding.

>     If they can't be used with libbsd (or another stack) I would suggest to
>     keep them together with the legacy stack in your new libnetworking
>     repository.
> 
> 
> +1 

+1

>     > 2. There are a few header files in cpukit/include that are required by
>     > the libnetworking stack. Currently the rtems-libnetworking is building
>     > in sort of a hackish way by using the header file from the RTEMS source
>     > directory. Do we want to add these header files (like tftp.h) and
>     > related source files to the libnetworking directory? The other way to
>     > use them would be to install the required headers in the PREFIX and use
>     > them from libnetworking.
> 
>     If I understand correctly, the headers are not installed? In that case:
>     Who else uses these headers? If no one except for the network stack
>     needs them: Move them to your new library.
> 
> +1 

+1

>     In case of the tftp.h: It seems that this file is installed, isn't it?
>     So why can't you just use it from libnetworking?
> 
> Hmm... that appears to be used only by the tftp client filesystem. That should
> be in libfs/src really.  There is also an ftp client filesystem which also needs to
> move. They SHOULD work independent of the network stack.
> 
> Move those files so either stack can use them.
> 
> I'm thrilled to see this happening.

I am as well. Vijay thank you for taking on the task.

Chris