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

["Miquel van Smoorenburg" <miquels@cistron.nl>]

In article <ann5s4$87a$1@ncc1701.cistron.net>,
Miquel van Smoorenburg <miquels@cistron.nl> wrote:
>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.

That doesn't work since other OSes redirect both input and
output, and while we don't do that we don't want to change
semantics too much.

How about _not_ doing the redirect for filehandles opened
with O_DIRECT ?

--- linux-2.4.19/drivers/char/tty_io.c.orig	Sat Aug  3 02:39:43 2002
+++ linux-2.4.19/drivers/char/tty_io.c	Wed Oct  9 20:01:26 2002
@@ -755,7 +755,7 @@
 	is_console = (inode->i_rdev == SYSCONS_DEV ||
 		      inode->i_rdev == CONSOLE_DEV);
 
-	if (is_console && redirect)
+	if (is_console && redirect && !(file->f_flags & O_DIRECT))
 		tty = redirect;
 	else
 		tty = (struct tty_struct *)file->private_data;

Mike.