Standalone repository for libnetworking stack
Vijay Kumar Banerjee
vijay at rtems.org
Fri Feb 5 23:17:15 UTC 2021
Hello Christian, Joel, Chris,
On Fri, Feb 5, 2021 at 3:41 PM Chris Johns <chrisj at rtems.org> wrote:
> 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  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 .
> 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.
I do have some repos in my area in dispatch.rtems.org but for some
reason they don't appear in git.rtems.org page that's why I pushed it
in github. Am I possibly missing some step?
> > 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.
That's a good point!
> > We could make it painful and obvious using something like
> > rtems-legacy-networking :)
> .. or rtems-net-legacy ... small, clear and simple.
rtems-net-legacy sounds right, I'll rename.
> > 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?
Currently it builds for all BSPs, like libbsd.
> > 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.
Understood. I'm not sure if they're used with libbsd but I think
they're not as they're only built with RTEMS_NETWORKING enabled. I'll
move them to the new repo.
> > 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?
I think I missed it while checking for the include paths in waf, I can
check it again. If it works out, then I guess my question is already
> > 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.
This point is not clear to me. Do I add a copy of them in the network stack ?
> > I'm thrilled to see this happening.
> I am as well. Vijay thank you for taking on the task.
> devel mailing list
> devel at rtems.org
More information about the devel