<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 10, 2021 at 11:48 AM Chris Johns <<a href="mailto:chrisj@rtems.org">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 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>>> 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>>> 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>>> wrote:<br>
> > >> On Tue, Mar 9, 2021, 3:28 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>>> wrote:<br>
> > >>> On Fri, Mar 5, 2021 at 10:03 AM 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>>> wrote:<br>
> > >>> In this proposed set of patches, I have removed telnetd from 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 from the<br>
> > >>> legacy net repo? There are checks in for RTEMS_NETWORKING in telnetd,<br>
> > >>> to add rtems_bsdnet.h, how do we want to deal with that? In the 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 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>
> ><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 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></blockquote><div><br></div><div>Maybe the answer is that there should be no network services in rtems.git.</div><div><br></div><div>Clone and own remainder in rtems.git to legacy and libbsd. We can then lean</div><div>to freezing, patching, or replacing as appropriate for each stack. Legacy leans </div><div>to freeze but I can see some fixes applied to a copy in both. </div><div><br></div><div>But say we port a new webserver to RTEMS. I'm guessing it would go with libbsd</div><div>and we would ignore ir for legacy. </div><div><br></div><div>We can revisit this with lwip. It may not be able to support some of these services</div><div>anyway. If it can, we patch in two places. This stuff rarely changes.</div><div><br></div><div>And as I say rarely changes, I expect a deluge of improved network services. LOL</div><div><br></div><div>--joel</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div>