Standalone repository for libnetworking stack

Tue Mar 23 19:10:42 UTC 2021

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.

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?

> 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