On 11/3/21 1:11 am, Joel Sherrill wrote: > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <vi...@rtems.org > <mailto:vi...@rtems.org>> wrote: > > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > > > > On 10/3/21 3:51 pm, Gedare Bloom wrote: > > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill <j...@rtems.org > <mailto:j...@rtems.org>> wrote: > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee <vi...@rtems.org > <mailto:vi...@rtems.org>> wrote: > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee > <vi...@rtems.org > <mailto:vi...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel