On Thu, 24 Jan 2002, Greg A. Woods wrote:

> [ On Thursday, January 24, 2002 at 12:36:25 (-0800), Bill Studenmund wrote: ]
> > Subject: Re: TTY virtualization driver
> >
> > Yes, but the other examples are just that, other. I think the point is
> > that ttys stick in people's heads differently than say audio devices or
> > scsi disks. So it makes sense to tie them down differently.
>
> Well, ttys are getting to be pretty archaic things, and perhaps my vast,
> but now long past, experiences with using them extensively is biasing my
> desire to have them behave more uniformly.  While not everyone builds
> terminal servers, UUCP dial-out gateways, etc., these days, they are
> still viable applications for NetBSD.

The reason we have a Cyclades Y & Z driver is because Zembu found serial
consoles to be very useful. They ain't dead yet. :-)

> To my mind if I have N serial ports in a given machine then it should
> have /dev/tty0 through /dev/ttyN (with any number of leading zeros to
> appease those such as myself who like such things).  It does not matter
> if two or a few are on the CPU board, and another four are on some card
> plugged into one type of bus, and another 128 or more are plugged into
> four or more cards on yet another type of bus, and so on, and so on.

Well, it does matter if you care where the tty goes. To physically map
where a serial line goes, you have to know what plug it goes to, and what
device node that's hooked to.

> > Fear mongering?
>
> The mapping of /dev/console is not going to move in any sane real-world
> kernel configuration no matter how many serial port cards are flipped
> around in any given machine.  Suggesting that it will and using that as
> an excuse not to have a "virtual" tty driver upper layer to hide the
> irrelevant differences in low-level serial port drivers is most
> definitely fear mongering.

When was that done? I did not take away from this conversation that
/dev/console should be changed, nor that it's existance is a reason to not
have "virtual" ttys.

> /dev/console will always remain mapped to the physical device that will
> most likely be the boot console on any given machine architecture.  Sure

That should be the device the bootloader told us was the console. It's not
a matter of likely, it's stronger than that. /dev/console is where the
kernel has been sending messages, and where it will chat with ddb. :-)

Take care,

Bill