Standalone repository for libnetworking stack

Tue Mar 23 18:34:17 UTC 2021

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?

And to make a news announcements.

--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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210323/d5a9eb71/attachment.html>