[PATCH rtems-libbsd] Import telnetd from RTEMS repository

[Gedare Bloom]

On Thu, Apr 8, 2021 at 2:18 AM Sebastian Huber
<sebastian.huber at 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.huber at 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<gedare at 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.

> 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.huber at 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/
>