On Tue, Mar 23, 2021 at 11:27 AM Vijay Kumar Banerjee <vi...@rtems.org> wrote:
> 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. > Great! Is there any reason not to move the repo to the top level and delete the networking from the main rtems repository? And to make a news announcements. --joel > > > 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