Standalone repository for libnetworking stack

Fri Feb 5 23:34:17 UTC 2021

On Fri, Feb 5, 2021, 5:17 PM Vijay Kumar Banerjee <vijay at rtems.org> wrote:

> 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 [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.
> >
> 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
> >
> > +1
> >.
>
> Ok.
>

Simple rule. If in libbsd and cpukit, move cpukit version to legacy. If
only in cpukit, it is supposed to work on both.

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

No. Move them to libfs so either stack can use them. They should be
independent.

>
> > > I'm thrilled to see this happening.
> >
> > I am as well. Vijay thank you for taking on the task.
> >
> :)
> > Chris
> > _______________________________________________
> > 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/65900213/attachment-0001.html>