[PATCH rtems-libbsd] Import telnetd from RTEMS repository

[Sebastian Huber]

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:

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/