I am porting an application to uClinux which I want to be able to
control via telnet. Actually, I want to allow multiple simultaneous
telnet sessions that all control the same instance of the program (or
at least the same "core" of the program). Let me explain...
The original (non uClinux) version supported multiple command line
interfaces. For the sake of argument, think of it as having a
quad-uart, with each uart connected to a separate serial terminal. A
single executable serviced all of the terminals, polling each in
turn, processing commands, updating values in memory, and controlling
hardware. Because everything was done from a single executable, a
command could be entered from any one of the terminals and it would
update the same values in memory and control the same hardware.
My initial uClinux port runs fine using the serial port as a command
line interface (there is only one serial port in this version of the
hardware). I can also telnet to uClinux (getting the msh shell from
BusyBox) and run it from there. I can create multiple telnet
sessions and run a separate instance of the program from each. That
is almost what I am looking for, except that I have a completely
separate instance of the executable running for the serial port and
each of the telnet sessions, and no good way to keep a common set of
values in memory nor to determine which instance of the program
should control the hardware.
It seems to me that I need to break my application into at least two
executables, a "core" that would control the hardware, and a separate
program that would communicate with the core and provide a command
line interface (a custom shell). This would be very similar in
concept to the Linux kernel and having multiple consoles running
Bash. I am struggling to figure out the best way to make the core
and custom shell communicate. I would be grateful for any suggestions.
-----------------
I have considered a variety of options for making the core and custom
shell communicate, but I don't understand the "Unix Way" of doing
things well enough to know which to pursue. The following are some
of my thoughts; they may or may not make sense.
Because the original application already knows how to service
multiple command line interfaces, it seems like it would be
straightforward to make the "core" provide four virtual serial ports
(to correspond with the original quad uart) and make each instance of
the custom shell connect to one of them, print any output and return
any keyboard input. The virtual serial port could maybe be a socket
or something in the /dev directory (I don't understand how they work
yet). The custom shell could try to connect with each of the virtual
serial ports in turn until it found one that wasn't already in
use. Obviously the number of custom shells that could be used at one
time would be limited by the number of virtual serial ports.
I have been reading online about the following, but I haven't quite
been able to figure out how they apply to my situation:
- Unix shells (changing the shell with chsh, etc)
- Consoles
(<http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-7.html#ss7.1>http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-7.html#ss7.1
and others)
- Virtual consoles (from http://en.wikipedia.org/wiki/Virtual_console
and
<http://www.bellevuelinux.org/console.html>http://www.bellevuelinux.org/console.html)
- Pseudo terminals (from
<http://en.wikipedia.org/wiki/Pseudo_terminal>http://en.wikipedia.org/wiki/Pseudo_terminal)
- TTY drivers (from Chapter 18 of "Linux Device Drivers")
- getty (from http://www.busybox.net/downloads/BusyBox.html#item_getty)
- inetd (from
<http://en.wikipedia.org/wiki/Inetd>http://en.wikipedia.org/wiki/Inetd)
It seems that virtual consoles are close to what I want ("A virtual
console...is a conceptual combination of the keyboard and the display
for a user interface...represented by device special files /dev/tty1,
/dev/tty2 etc."), but this part doesn't apply, "...accessed from the
same physical console (i.e., same keyboard and screen)." I don't
think I need to use multiple virtual consoles provided by the Linux
kernel as they would just let me run multiple instances of my
program; I think I need to implement similar "device special files"
that my custom shell could connect with. Am I even on the right
track? Is there a better way?
Thanks for any pointers/suggestions you can give me.
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:[EMAIL PROTECTED]
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
