On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote:
> On Tue, Mar 9, 2021 at 9:56 PM Chris Johns <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> wrote: > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee <vi...@rtems.org> > wrote: > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee < > 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 > > > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel