Hi Steve, What, you give up on RTEMS? ;-)
Or are you like me, working on multiple platforms? Take care, -Bob RSG Associates 84 Spring Street West Roxbury, MA 02132 www.rsgassoc.com Steve Strobel wrote: > 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 > > _______________________________________________ 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
