Quote:
If I understand you correctly, you assert that the correct way to do this is to make my application into a daemon that starts from an /etc/rc#.d script and uses the other serial port for interraction while leaving the "primary" serial port for normal console logins.

Yes, and while I am something of a pedant for "correct"ness, it's your computer and you can do what you want with it. My point is less that it's correct and more that it's actually probably less effort to do it this way and still maintain the ability to administer the computer. What I mean by that is if something goes wrong with your program, the ability to be able to log in elsewhere is probably going to be nice.

Quote:
Console spam?

By that I mean all the stuff that gets spewed to the console, from syslog stuff to the kernel and drivers printing out information. That actually brings up another point. You say you want it to run when there are not users there. That might imply that there's going to be another computer listening to that serial port. If so, all the bootup info might confuse it. Certainly avoiding it would be easier. Then again, you might just want people to be able to see output when they check it.

Quote:
My app dumps some status info to the console while running.

The console is a separate entity from the primary serial device. They happen to share the same hardware in this case, but that doesn't mean that they are inherently related. What I'm getting at is are you redirecting that info to /dev/console or are you just printing it out on stdout? If it's the latter, then I don't think that this is anything to worry about.

It occurs to me that I'm busy telling you what you can't and shouldn't do and less what will work. Again, you can replace init with a program that loops and does what you want, but that means that you lose an actual console. This is the way the empeg works. You can, IIRC, tell getty to use a different program than login, so you could either tell it to use your program and have your program be able to fork a shell in the foreground or you could use a script that calls your program, then the shell (init will restart the getty when it exits, assuming you give it the respawn parameter, so it need not loop itself). You could also do the same thing without getty, but getty does some nice stuff for you, like dealing with the serial port so that your program can just use stdin and stdout. Those are the ways that occur to me immediately. I'd go with the getty option myself. Note that there are a number of versions of getty for Linux. Make sure that you read the correct documentation. (I've lost a few hours wondering why those documented options didn't work before I realized I was using a different getty than the one I was reading documentation for.)

And since the steps for configuring getty are the same regardless of whether you use the console port or the other port, I'd personally go with the other port. In fact, if I were to go with the console port, I'd make sure to configure the other port so that it can accept logins.


Edited by wfaulk (09/10/2005 23:07)
_________________________
Bitt Faulk