Quote:
in the case of a daemon, it is obviously not proper to interract over STDIN and STDOUT.
Of course it can be. You just have to make sure that stdin and stdout point to the right things. In fact, the network superserver, inetd, presents network communications to the service apps as stdin and stdout. The gettys you're trying to use will present the appropriate things as serial ports.
Quote:
I just dont think it's that big of a stretch to ask if there is some way to get this embedded box to automatically log in as "user"
There is no way to automatically log in. You can circumvent the things that allow you to log in in the first place to grab the console and run your program there, but that will prevent you from being able to drop back to a shell unless you add something else that makes that shell happen. And you can do the same thing on your other serial port without disabling normal access to your console.
Quote:
I am reluctant to give up my console access to the application and move it to another serial port
I'm not really sure what you think you'll be giving up. Do you want to avoid having the ability to run the program and have a console at the same time? Do you think that getting it to run on that other serial port is going to be more difficult than getting it working on the console? Do you think you'd have more console access if it was not on a different serial port? Do you think that you wouldn't be able to access a shell if it was on a different serial port? Do you need to see console spam while running the application? Do you need to be able to do absolutely everything over one serial port?
Quote:
there is so much hatred and flaming
I don't hate you and I'm not flaming you. I'm trying to prevent you from doing something that I think is going to require more work and be more difficult to maintain while also lessening your access to the computer than doing it the "correct" way to begin with.
What I'm getting at is that the difference between the steps to make what you want happen and running it as a daemon on the other serial port are virtually identical with the addition in doing it your way of needing to disable the default console.
Actually, I suppose that's not true. As stated, you can replace the init binary with one you create yourself that will do nothing but run your program and run a shell in a loop. Again, that would disable normal console access completely and you'd have to write additional stuff to make sure that you are the correct user at the correct time. My suggestion means that you'd have to figure out how to configure your second serial port's getty properly to run your program instead of a shell. (Or, as Peter suggested, not use getty at all, but replace it with a call to your program, but, again, that means you wouldn't have any shell access on that serial port without modifying your program to be able to start one itself.)
_________________________
Bitt Faulk