<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 11:27 AM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org">vijay@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>I have prepared and rebased all the patches to the current master. Please review the commits.<br><br><div>RTEMS patches: <a href="https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet" target="_blank">https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet</a></div><div>RTEMS net-legacy patch to pull recent changes: <a href="https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e" target="_blank">https://git.rtems.org/vijay/rtems-net-legacy.git/commit/?id=2b4738734f9d678a458b64278c0ff95dea588b1e</a></div><div>RTEMS libbsd patch to add telnetd:<a href="https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541" target="_blank"> https://git.rtems.org/vijay/rtems-libbsd.git/commit/?id=6bda703964e8cbbf73cb21f52fb7ceeb3cb3a541</a></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Great! Is there any reason not to move the repo to the top level and delete the networking from the main rtems repository?</div><div><br></div><div>And to make a news announcements.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>Best regards,</div><div>Vijay<br></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 10, 2021 at 11:43 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 11/3/21 5:14 am, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Wed, Mar 10, 2021 at 11:48 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
> <br>
> <br>
> <br>
> On 11/3/21 1:11 am, Joel Sherrill wrote:<br>
> > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a><br>
> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>><br>
> > <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>>>> wrote:<br>
> ><br>
> > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>><br>
> > <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>>> wrote:<br>
> > ><br>
> > > On 10/3/21 3:51 pm, Gedare Bloom wrote:<br>
> > > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>><br>
> > <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>>> wrote:<br>
> > > >> On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee<br>
> <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>><br>
> > <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>>>> wrote:<br>
> > > >>> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee<br>
> <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>><br>
> > <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>>>> wrote:<br>
> > > >>> In this proposed set of patches, I have removed telnetd from<br>
> RTEMS and<br>
> > > >>> have placed it in the net-legacy repo, it seems like libbsd uses<br>
> > > >>> telnetd as well. Do we want to keep it in RTEMS and remove it<br>
> from the<br>
> > > >>> legacy net repo? There are checks in for RTEMS_NETWORKING in<br>
> telnetd,<br>
> > > >>> to add rtems_bsdnet.h, how do we want to deal with that? In the<br>
> legacy<br>
> > > >>> repo, we can just remove these checks and let them build.<br>
> > > >><br>
> > > >><br>
> > > >> Move it and remove rtems networking conditional. Freezes it with<br>
> legacy<br>
> > stack.<br>
> > > >><br>
> > > >> Just my opinion<br>
> > > >><br>
> > > > Is there a different telnetd in libbsd?<br>
> > ><br>
> > > Yes ...<br>
> > ><br>
> > > <a href="https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd</a><br>
> <<a href="https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd</a>><br>
> > <<a href="https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd</a><br>
> <<a href="https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/telnetd</a>>><br>
> > ><br>
> > This seems to include rtems/telnetd.h<br>
> > Does the libbsd telnetd depend on the cpukit/telnetd?<br>
> ><br>
> > > > The longer term pseudo-goal of being able to (potentially) build<br>
> > > > multiple networking stacks and pick which one to link against may also<br>
> > > > be a consideration at this stage.<br>
> > ><br>
> > > Are there issues? If there are issues do we know what they are?<br>
> ><br>
> ><br>
> > I guess the bigger question is what network services should remain in<br>
> > rtems itself and work with any stack. <br>
> ><br>
> > We have at least telnetd and the web server. If they build against the<br>
> > standard network headers, then they should work any stack that uses<br>
> > those. <br>
> ><br>
> > For maintenance, it would be preferable to only have one which all<br>
> > stacks use. But this means rtems itself could be built with network <br>
> > services and no stack. I guess this is preferable to having:our own <br>
> > cross stack network services package.<br>
> ><br>
> > + RTEMS kernel<br>
> > + pick your stack<br>
> > + RTEMS specific network services<br>
> > + Ports of standard network services (SNMP, NTP, ACE/TAO, etc)<br>
> ><br>
> > At this point, it concerns me to add more and more packages because we<br>
> > tend to not have automation to build/test as many beyond the core RTEMS <br>
> > as we should.<br>
> ><br>
> > Based on that alone, I'd prefer to unify "RTEMS specific network services"<br>
> > under rtems.git for now. If the service is specific to the stack, put it<br>
> with it,<br>
> > If it is a third party package, it is an RSB issue.<br>
> <br>
> I think this should be "where they can". For example the NFSv2 client depends on<br>
> RPC and that is different. I suspect this is why we need a copy with each<br>
> networking stack.<br>
> <br>
> The down side of having these services in rtems.git is no testing. You cannot<br>
> create a test executable in rtems.git because you cannot reach up the vertical<br>
> stack.<br>
> <br>
> <br>
> Maybe the answer is that there should be no network services in rtems.git.<br>
> <br>
> Clone and own remainder in rtems.git to legacy and libbsd. We can then lean<br>
> to freezing, patching, or replacing as appropriate for each stack. Legacy leans <br>
> to freeze but I can see some fixes applied to a copy in both. <br>
> <br>
> But say we port a new webserver to RTEMS. I'm guessing it would go with libbsd<br>
> and we would ignore ir for legacy. <br>
> <br>
> We can revisit this with lwip. It may not be able to support some of these services<br>
> anyway. If it can, we patch in two places. This stuff rarely changes.<br>
<br>
All this sounds fine.<br>
<br>
> And as I say rarely changes, I expect a deluge of improved network services. LOL<br>
<br>
Yeah I suppose it will. Oh well.<br>
<br>
Chris<br>
</blockquote></div>
</blockquote></div></div>