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