Messages in this thread | | | From | "Miquel van Smoorenburg" <> | Subject | Re: Why does x86_64 support a SuSE-specific ioctl? | Date | Sat, 5 Oct 2002 17:00:52 +0000 (UTC) |
| |
In article <1033824115.3425.2.camel@irongate.swansea.linux.org.uk>, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >I see no good reason for this ioctl at all, in any tree.
Check out 'bootlogd.c' in sysvinit.
It starts at boot time, created a tty/pty pair, and does a TIOCCONS on it. Everything that gets written to /dev/console now goes ty the pty, so it can log all output.
However you still want to see the output on the screen. But you can't copy it to /dev/console, because you'd get it right back in the pty.
So you need to know what the _real_ console is so you can write a copy to the real console. The only way to find that out is to call TIOCGDEV on /dev/console, then scan /dev. That is what bootlogd does, I've tried to get TIOCGDEV in the kernel since 2.2 days but gave up because it was ignored. So bootlogd has always been 'experimental', though it is very useful, since it has no kernel support.
Now, to solve this particular problem, there are a few alternatives.
One is a TIOCCONS_COPY ioctl, so that output is not redirected but copied to the pty.
Another, perhaps more elegant solution is that writes to the pty slave that receives the console output should go to the real console. A swap instead of a redirect.
The last one probably makes more sense - it seems very logical, and is trivial to implement.
Mike.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |