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