Subject: Re: On /dev/console, /dev/constty and the TIOCCONS ioctl
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 10/03/2003 18:15:56
[ On Friday, October 3, 2003 at 17:46:46 (-0400), Todd Vierling wrote: ]
> Subject: Re: On /dev/console, /dev/constty and the TIOCCONS ioctl
>
> Um, why don't you just set your gettytab to put terminals on the physical
> device(s) (such as /dev/tty00 for serial, /dev/ttyE0 for wscons)?

/dev/constty really does make a lot more sense.

>  This
> would give you the ability to do TIOCCONS as you desire, without adding yet
> another kernel layer.

It's not another "kernel layer" -- it's just another minor device node
for an existing device driver.

Also, if I'm not mistaken, getty still fails (and thus causes init to go
into a loop restarting it) if the "standard" framebuffer console device
(/dev/ttyE0 for wscons) is not configured (e.g. when the hardware is not
there).  Why should every administrator on the planet be forced to
modify /etc/ttys every time they configure a system with only a serial
console?

> This is how some ports used to be configured by default:  physical device
> has a getty, but /dev/console is more-or-less write-only by console-logging
> stuff.

(I hope you really meant "read-only".)

It makes a lot more sense, and is a heck of a lot more portable across
all platforms, to always have a just one standard getty entry in
/etc/ttys for the ``console'' device, and given the limitations of
TIOCCONS along with the current uses of the string "/dev/console" it
makes the most sense to have a separate minor device and thus a separate
device file pathname, just as David has implemented, to use for that
getty process.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>