On Tue, 12 Sep 2000, Miquel van Smoorenburg wrote:
> It is a tty, it's just that if you open(2) it, it doesn't become
> your _controlling_ tty by default. See drivers/char/tty_io.c (I
> think, that's from the top of my head).
Then I guess the kernel doesn't perform the proper setup when it opens
/dev/console and then hands it over to init. Indeed, main.c simply opens
/dev/console, dup()'s the descriptor twice (for stdout and stderr) and
then exec's init.
> You can always force it to become the controlling tty using TIOCSCTTY,
> but that is kind of hard in a shell script. But the trick with
> reopening stdin/stdout/stderr using /dev/tty1 should work.
I don't want to rely on /dev/tty1. Many of my machines are on serial
console, so that would be wrong anyway. The problem is that sometimes
there is a problem in the start-up process, and I get a sulogin prompt
which I can't even ctrl-d to continue!
Maybe I'll play with main.c and see what happens if I force /dev/console
to become the controlling tty for init. Hmm... That could be dangerous for
init. Maybe a better idea would be to hack init so that it gives any
program started from inittab /dev/console as the controlling tty.
You're the sysvinit maintainer, right? :) What do you think of this idea?
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:17 EST