Re: Why does x86_64 support a SuSE-specific ioctl?

Miquel van Smoorenburg (miquels@cistron.nl)
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/