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>