Standalone repository for libnetworking stack
Vijay Kumar Banerjee
vijay at rtems.org
Thu Apr 8 01:17:26 UTC 2021
On Mon, Apr 5, 2021 at 4:09 PM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Tue, Mar 23, 2021 at 2:12 PM Vijay Kumar Banerjee <vijay at rtems.org> wrote:
> >
> > 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.
> >
> I think, push the RTEMS patch to remove the libnetworking on Wed, with
> everything else. Prepare to deal with any complaints and patches/quick
> fixes on Thursday and Friday. :)
>
Thank you. Pushed.
> > > > 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