[PATCH rtems-libbsd] Import telnetd from RTEMS repository

Fri Apr 9 12:49:49 UTC 2021

On Thu, Apr 8, 2021 at 10:31 AM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>

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.

> > 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/
> >
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210409/bd53e6e5/attachment-0001.html>