This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: telnet
- To: jtroeger at nortelnetworks dot com
- Subject: Re: [ECOS] Re: telnet
- From: Bart Veer <bartv at redhat dot com>
- Date: Mon, 21 Aug 2000 13:56:56 +0100
- CC: ecos-discuss at sources dot redhat dot com
- References: <04b601c00b71$455210b0$24313fc3@jtpc>
- Reply-to: bartv at redhat dot com
>>>>> "Joerg" == Joerg Troeger <jtroeger@nortelnetworks.com> writes:
Joerg> From: Gary Thomas <gthomas@redhat.com>
>> On 21-Aug-2000 Joerg Troeger wrote:
>> > Is there a hope for getting telnet access also in the short future?
>>
>> Exactly what would you use 'telnet' access for? Since telnet is
>> used for interactive connections to a "host", it doesn't seem
>> to have a lot of application here.
Joerg> Gary,
Joerg> our embedded system will be the "host".
Joerg> In our embedded system we need:
Joerg> - TCP/IP access for the application
Joerg> - DHCP for diskless system comeup/software verification and
Joerg> update mechanism
Joerg> - SNMP for management support from the customers network
Joerg> admin and
Joerg> - telnet access for special vendor configuration, debug &
Joerg> support purposes.
Joerg> Our lab-system has a serial interface, which offers some
Joerg> special powerful builtin "shell commands". This serial
Joerg> interface will vanish in the release system, therefore
Joerg> thecommands should be available via telnet also. It gives
Joerg> us the opportunity to have a close look at our system via
Joerg> remote access. "Telnet access" means network files for
Joerg> stdin & stdout, a network tty or something else.
Joerg> This sort of telnet access seems to be widely spread to
Joerg> network-aware embedded systems.
Joerg> Should we spent effort in implement telnet support by
Joerg> ourselves (this seems stupid if redhat is doing the same)?
I think the confusion here is because of the term "telnet". This
implies a telnetd running under eCos (possibly inetd as well), pseudo
terminals, fork()'ing and exec()'ing a shell, and having the shell
fork and exec commands loaded of a disk somewhere. That sort of
functionality is not appropriate for eCos.
However, having a dedicated interpreter (Tcl, Python, hand-crafted,
whatever) embedded into your application, accepting connections on a
specific socket and responding to selected commands on that socket,
would be a reasonable approach for many applications. Having
pseudo-tty support may or may not be appropriate: it might make things
a bit easier for the interpreter, but there is a risk that a lot of
the pseudo-tty functionality would never be used yet still consume
code and data space.
AFAIK Red Hat is not currently working on anything along these lines.
Bart Veer // eCos net maintainer