Standalone repository for libnetworking stack

[Chris Johns]

On 11/3/21 5:14 am, Joel Sherrill wrote:
> 
> 
> On Wed, Mar 10, 2021 at 11:48 AM Chris Johns <chrisj at rtems.org
> <mailto: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>
>     > <mailto: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>
>     >     <mailto: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>
>     >     <mailto: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>
>     >     <mailto: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>
>     >     <mailto: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>
>     >     <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.

All this sounds fine.

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

Yeah I suppose it will. Oh well.

Chris