<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 11:00 PM 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">On Tue, Mar 9, 2021 at 9:56 PM Chris Johns <<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>> 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>> 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>> 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 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>
><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></blockquote><div><br></div><div>I guess the bigger question is what network services should remain in</div><div>rtems itself and work with any stack. </div><div><br></div><div>We have at least telnetd and the web server. If they build against the</div><div>standard network headers, then they should work any stack that uses</div><div>those. </div><div><br></div><div>For maintenance, it would be preferable to only have one which all</div><div>stacks use. But this means rtems itself could be built with network </div><div>services and no stack. I guess this is preferable to having:our own </div><div>cross stack network services package.</div><div><br></div><div>+ RTEMS kernel<br></div><div>+ pick your stack<br></div><div>+ RTEMS specific network services<br></div><div>+ Ports of standard network services (SNMP, NTP, ACE/TAO, etc)<br></div><div><br></div><div>At this point, it concerns me to add more and more packages because we</div><div>tend to not have automation to build/test as many beyond the core RTEMS </div><div>as we should.<br></div><div><br></div><div>Based on that alone, I'd prefer to unify "RTEMS specific network services"</div><div>under rtems.git for now. If the service is specific to the stack, put it with it,</div><div>If it is a third party package, it is an RSB issue.</div><div><br></div><div>--joel</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>