Standalone repository for libnetworking stack
Vijay Kumar Banerjee
vijay at rtems.org
Tue Mar 23 16:27:34 UTC 2021
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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210323/295665bd/attachment-0001.html>
More information about the devel
mailing list