<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 8, 2021 at 10:31 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@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 Thu, Apr 8, 2021 at 2:18 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 08/04/2021 08:09, Gedare Bloom wrote:<br>
><br>
> > On Wed, Apr 7, 2021 at 11:10 PM Sebastian Huber<br>
> > <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>  wrote:<br>
> >> On 08/04/2021 03:17, Vijay Kumar Banerjee wrote:<br>
> >><br>
> >>> On Mon, Apr 5, 2021 at 3:48 PM Gedare Bloom<<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>   wrote:<br>
> >>>> push this if no one complains by Wednesday<br>
> >>>><br>
> >>>> I think we should keep this telnetd and the legacy one in sync for<br>
> >>>> now, and consider them as a good candidate for a new<br>
> >>>> 'rtems-net-services' repository.<br>
> >>>><br>
> >>> Thanks. Pushed.<br>
> >> Sorry for being late, but why was this added to libbsd? Most parts of<br>
> >> the telnetd are network stack independent, see also:<br>
> >><br>
> >> <a href="https://devel.rtems.org/ticket/3419" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3419</a><br>
> >><br>
> >> One reason to have the socket API in Newlib was to be able to write<br>
> >> network stack independent software. If this code is now duplicated, then<br>
> >> this is a step backwards.<br>
> >><br>
> > Yes, this is probably an intermediate step. I have asked Vijay to look<br>
> > at the idea of creating a repo for these network services.<br>
> > Unfortunately, there were a few lines of code in the telnetd that<br>
> > seemed to be enabled only for the legacy stack, so it seems the<br>
> > telnetd isn't totally stack independent. In case some minor adaptation<br>
> > seems to be necessary based on the network stack, and we can't know<br>
> > what that stack will be for sure at RTEMS build time since we<br>
> > eliminated those configuration options. So, it doesn't make sense to<br>
> > keep these network services in rtems.git, without having a network<br>
> > stack?<br>
> It makes no sense to remove these services from rtems.git from my point<br>
> of view. The  tftpfs, ftpfs, ftpd, telnetd, and libdebugger services<br>
> depend only on the socket API with some minor exceptions which are easy<br>
> to abstract.<br>
> ><br>
> > I anticipate that we will attempt to migrate and merge the network<br>
> > services, starting with telnetd, into a new repo that can be built<br>
> > after the user selects their network stack. Our first priority is to<br>
> > get things separated from rtems.git, and to get an lwip stack up in<br>
> > parallel. Then, we would like to see how well the telnetd code base<br>
> > can work with lwIP. Probably, we will get this done in the summer.<br>
> ><br>
> > Other ideas are welcomed.<br>
><br>
> I would keep the services in rtems.git and add APIs for the things which<br>
> depend on RTEMS_NETWORKING. Then implement the API in the network<br>
> stacks. It is not that much:<br>
><br>
OK, this seems like a fine idea. We'll get a proposal for API together<br>
shortly. For telnetd I think it requires some way to define the<br>
network task priority, or perhaps to obtain the network task id so<br>
that then its priority can be obtained from usual rtems APIs.<br></blockquote><div><br></div><div>FWIW network task priority was configurable in the legacy stack and I </div><div>don't think it is with libbsd. I found where it is set but no obvious way for</div><div>the user to impact. The ability to control this was a critical feature and</div><div>addresses integration issues.</div><div><br></div><div>The rule would have to be that no conditional compilation based on </div><div>network stack can be used and the services would have to be restricted</div><div>to the set offered by LWIP. That's not that large a set of services but covers</div><div>a lot of the basics. But it is very easy to get beyond that. </div><div><br></div><div>There may also be an issue that any user deploying LWIP is targeting</div><div>a low resource target board and needs trimmed down versions of the</div><div>various services. </div><div><br></div><div>Addressing API commonality between the two stacks for common </div><div>configuration and setup is good. I recall Peter Dufault submitted</div><div>a patch a while back to align some RTEMS specific API in dhcp.</div><div><br></div><div>I don't mind pushing this noodle up the hill a bit since rtems-lwip isn't</div><div>there yet but we shouldn't be surprised that there are limits. We need</div><div>to be conscious of and capture those limits.</div><div><br></div><div>libdebugger is probably the only service that is tied enough to RTEMS</div><div>that moving it would be a pain for maintenance. The others are just </div><div>simple applications.</div><div><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>
> grep -r RTEMS_NETWORKING --include='*.[ch]' cpukit/<br>
> cpukit/ftpd/ftpd.c:#ifndef RTEMS_NETWORKING<br>
> cpukit/libtest/testbeginend.c:#if RTEMS_NETWORKING<br>
> cpukit/libtest/testbeginend.c:    " RTEMS_NETWORKING"<br>
> cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING<br>
> cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING<br>
> cpukit/include/rtems/shellconfig.h:#if RTEMS_NETWORKING<br>
> cpukit/include/rtems/shellconfig.h:    #if RTEMS_NETWORKING<br>
> cpukit/include/rtems/monitor.h:#if defined(RTEMS_NETWORKING)<br>
> cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING<br>
> cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING<br>
> cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING<br>
> cpukit/libnetworking/lib/tftpDriver.c:#ifdef RTEMS_NETWORKING<br>
> cpukit/libmisc/dummy/dummy-networking.c:#if defined(RTEMS_NETWORKING)<br>
><br>
> --<br>
> embedded brains GmbH<br>
> Herr Sebastian HUBER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> phone: +49-89-18 94 741 - 16<br>
> fax:   +49-89-18 94 741 - 08<br>
><br>
> Registergericht: Amtsgericht München<br>
> Registernummer: HRB 157899<br>
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
> Unsere Datenschutzerklärung finden Sie hier:<br>
> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>