* Greywolf puzzles over this.
Chris Torek sez:
/*
 * (someone(greywolf?) said):
 * >my feeling on this is that anyone with read access on
 * >/dev/console should be able to do a TIOCCONS.
 * 
 * There is a simple method for achieving this: make an ioctl operation
 * that works on /dev/console, NOT on the target fd, and do:
 * 
 * 	fd = open("/dev/console", O_RDWR);	/* or whatnot */
 * 	if (fd < 0) ... error ...
 * 
 * 	whereto = STDOUT_FILENO;		/* e.g. */
 * 	error = ioctl(fd, TIOCCONSREDIR, &whereto);
 * 
 * The code to handle the CONSREDIR ioctl would go in cons.c,
 * and would need to translate the fd to a vnode, etc.

Now, why make it this complicated?

You're passing an fd to TIOCCONS in the first place.

Every port I've known WRT TIOCCONS has been to just grab the damn thing.
It's mostly important for console OUTput.  Since the fd has a vp in it,
you should just be able to follow the vp, do the necessary checking,
do the redirection (or not) and return 0 (or <0).

 * 
 * Be sure to check for redirection-to-self (and maybe allow
 * redirection to fd "-1" to mean "end redirection).
 * 
 * The only drawback to this, aside from the specificity (perhaps
 * the ioctl should be fully general and allow redirecting data from
 * any fd, to any fd, in any direction), is that you then have to
 * modify xterm and xconsole to use the new ioctl.

That seems awfully complicated.

If you don't own the console, TIOCCONS shouldn't work.  End of story.

What am I missing?  mrg says it's not that easy, but I'm willing to
take a look at it and see what can be done.  There is an fhtovp call,
is there not?

Maybe this really is harder than it looks (I've been hit with that before).
Maybe this is easier than it looks.

 * Chris
 */





				--*greywolf;
--
# "Operator Precedence is that which causes statements such as *foo->bar to
# work properly.  It is also that which causes statements such as *foo->bar
# NOT to work properly."
# greywolf@starwolf.com