Standalone repository for libnetworking stack

[Chris Johns]

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.

Chris