Thus spake David Laight ("DL> ") sometime Today...

DL> So on an i386 system where the console tty is /dev/ttyE0 if anything
DL> opens /dev/ttyE0 (and nothing will stop it) then it will stop getty
DL> on /dev/console from working properly.

Not to be dense here, but I would hope that one isn't running gettys
on ttyE0 and console simultaneously.  I would expect this to "break",
i.e. "not work", simply because input won't know which way to go.

In short, "don't do that."

What happens if /dev/ttyE0 is the one with the getty, but stuff writes
to /dev/console?  I don't have any problems with this at all.  Under
normal operation, things won't be expecting to _read_ from /dev/console
and /dev/ttyE0 simultaneously.

What happens if /dev/console is the getty and stuff writes to /dev/console?
No big.  Systems have been working like this since the dawn of time.
It's messy, but that's normal.

But, again, if you're attempting to run things that *read* from /dev/console
and /dev/ttyE0 simultaneously, you're looking for trouble, xterm -C not-
withstanding.

[That's *weird*, xterm -C is.

	$ echo foo > /dev/console
	foo
	$ cat < /dev/console
	foo		#input
	foo		#output
	$
]

DL> I can't see anyway to fix this without putting knowlege of the
DL> console into genfs_revoke.
DL>
DL> The effects of the TIOCCONS ioctl don't bear thinking about.

				--*greywolf;
--
NetBSD: the second best thing you can get for free.