Standalone repository for libnetworking stack

[Joel Sherrill]

On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <vijay at rtems.org>
wrote:

> On Tue, Mar 9, 2021 at 9:56 PM Chris Johns <chrisj at rtems.org> wrote:
> >
> > On 10/3/21 3:51 pm, Gedare Bloom wrote:
> > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill <joel at rtems.org> wrote:
> > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee <vijay at rtems.org>
> wrote:
> > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee <
> vijay at rtems.org> wrote:
> > >>> In this proposed set of patches, I have removed telnetd from RTEMS
> and
> > >>> have placed it in the net-legacy repo, it seems like libbsd uses
> > >>> telnetd as well. Do we want to keep it in RTEMS and remove it from
> the
> > >>> legacy net repo?  There are checks in for RTEMS_NETWORKING in
> telnetd,
> > >>> to add rtems_bsdnet.h, how do we want to deal with that? In the
> legacy
> > >>> repo, we can just remove these checks and let them build.
> > >>
> > >>
> > >> Move it and remove rtems networking conditional. Freezes it with
> legacy stack.
> > >>
> > >> Just my opinion
> > >>
> > > Is there a different telnetd in libbsd?
> >
> > Yes ...
> >
> > https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd
> >
> This seems to include rtems/telnetd.h
> Does the libbsd telnetd depend on the cpukit/telnetd?
>
> > > The longer term pseudo-goal of being able to (potentially) build
> > > multiple networking stacks and pick which one to link against may also
> > > be a consideration at this stage.
> >
> > Are there issues? If there are issues do we know what they are?
>

I guess the bigger question is what network services should remain in
rtems itself and work with any stack.

We have at least telnetd and the web server. If they build against the
standard network headers, then they should work any stack that uses
those.

For maintenance, it would be preferable to only have one which all
stacks use. But this means rtems itself could be built with network
services and no stack. I guess this is preferable to having:our own
cross stack network services package.

+ RTEMS kernel
+ pick your stack
+ RTEMS specific network services
+ Ports of standard network services (SNMP, NTP, ACE/TAO, etc)

At this point, it concerns me to add more and more packages because we
tend to not have automation to build/test as many beyond the core RTEMS
as we should.

Based on that alone, I'd prefer to unify "RTEMS specific network services"
under rtems.git for now. If the service is specific to the stack, put it
with it,
If it is a third party package, it is an RSB issue.

--joel


> >
> > Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210310/2bf4b82f/attachment.html>