Standalone repository for libnetworking stack

[Joel Sherrill]

On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer <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].
>
> 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 :)

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

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?

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.


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


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

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

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

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

--joel


> Best regards
>
> Christian
>
> >
> > Any suggestions regarding these questions is greatly appreciated.
> >
> >
> > Best regards,
> > Vijay
> >
> > [1]: https://github.com/thelunatic/rtems-libnetworking
> > <https://github.com/thelunatic/rtems-libnetworking>
> > [2]: https://github.com/thelunatic/rtems/tree/no-libnet
> > <https://github.com/thelunatic/rtems/tree/no-libnet>
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210205/1cd1e15f/attachment.html>