Hi, I have prepared and rebased all the patches to the current master. Please review the commits.
RTEMS patches: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet RTEMS net-legacy patch to pull recent changes: https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e RTEMS libbsd patch to add telnetd: https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541 With these patches, the relocation work would be complete. I have tested all these patches are building with all the RTEMS bsps in bsp_defaults using waf. Best regards, Vijay On Wed, Mar 10, 2021 at 11:43 AM Chris Johns <chr...@rtems.org> wrote: > > > On 11/3/21 5:14 am, Joel Sherrill wrote: > > > > > > On Wed, Mar 10, 2021 at 11:48 AM Chris Johns <chr...@rtems.org > > <mailto:chr...@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 < > vi...@rtems.org > > <mailto:vi...@rtems.org> > > > <mailto: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> > > > <mailto: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> > > > <mailto: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> > > > <mailto: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> > > > <mailto: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> > > > <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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel