[PATCH rtems-libbsd] Import telnetd from RTEMS repository

Fri Apr 9 16:11:49 UTC 2021

Hi all,

On Fri, Apr 9, 2021 at 6:50 AM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> 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.
>

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.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
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel