Standalone repository for libnetworking stack

Vijay Kumar Banerjee vijay at rtems.org
Tue Mar 23 20:12:02 UTC 2021 

On Tue, Mar 23, 2021 at 1:10 PM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Tue, Mar 23, 2021 at 12:34 PM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Tue, Mar 23, 2021 at 11:27 AM Vijay Kumar Banerjee <vijay at 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?
> >
> It is: https://git.rtems.org/rtems-net-legacy/  -- I think he is
> asking to merge/update the repos. Vijay, I think you could send the
> net-legacy patch by itself to the list.
>
Thanks, sent it separately.

> I think  the big one is the RTEMS patches, and I'm not sure if the
> libbsd patches have been seen yet? @Vijay Can those be sent as an
> emailed patchset?
>
Sent just now. Thanks.

> > And to make a news announcements.
> >
> I think we had the announcement that it was pending, but yes it will
> be good to finalize that thread on the relevant mailing lists (users,
> EPICS-core). We think we hit most of the 'downstream' with those.
>
> > --joel
> >>
> >>
> >>
> >> Best regards,
> >> Vijay
> >>
> >>
> >> On Wed, Mar 10, 2021 at 11:43 AM Chris Johns <chrisj at rtems.org> wrote:
> >>>
> >>>
> >>>
> >>> On 11/3/21 5:14 am, Joel Sherrill wrote:
> >>> >
> >>> >
> >>> > On Wed, Mar 10, 2021 at 11:48 AM Chris Johns <chrisj at rtems.org
> >>> > <mailto:chrisj at 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 <vijay at rtems.org
> >>> >     <mailto:vijay at rtems.org>
> >>> >     > <mailto: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>
> >>> >     >     <mailto: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>
> >>> >     >     <mailto: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>
> >>> >     >     <mailto: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>
> >>> >     >     <mailto: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>
> >>> >     >     <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

More information about the devel mailing list