Standalone repository for libnetworking stack

[Joel Sherrill]

On Wed, Mar 10, 2021 at 11:48 AM Chris Johns <chrisj at rtems.org> wrote:

>
>
> On 11/3/21 1:11 am, Joel Sherrill wrote:
> > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <vijay at rtems.org
> > <mailto:vijay at rtems.org>> wrote:
> >
> >     On Tue, Mar 9, 2021 at 9:56 PM Chris Johns <chrisj at rtems.org
> >     <mailto: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
> >     <mailto:joel at rtems.org>> wrote:
> >     > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee <
> vijay at rtems.org
> >     <mailto:vijay at rtems.org>> wrote:
> >     > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee <
> vijay at rtems.org
> >     <mailto: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
> >     <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.
>
> I think this should be "where they can". For example the NFSv2 client
> depends on
> RPC and that is different. I suspect this is why we need a copy with each
> networking stack.
>
> The down side of having these services in rtems.git is no testing. You
> cannot
> create a test executable in rtems.git because you cannot reach up the
> vertical
> stack.
>

Maybe the answer is that there should be no network services in rtems.git.

Clone and own remainder in rtems.git to legacy and libbsd. We can then lean
to freezing, patching, or replacing as appropriate for each stack. Legacy
leans
to freeze but I can see some fixes applied to a copy in both.

But say we port a new webserver to RTEMS. I'm guessing it would go with
libbsd
and we would ignore ir for legacy.

We can revisit this with lwip. It may not be able to support some of these
services
anyway. If it can, we patch in two places. This stuff rarely changes.

And as I say rarely changes, I expect a deluge of improved network
services. LOL

--joel



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