[ 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.

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.

In the good old days when one vendor controlled all the hardware and all
the software (and many/most of the applications! :-), we usually had
only had one type of serial driver and all your /dev/ttyN's were
probably given one device major number (as they were on AT&T 3B2's, even
with different types of serial cards, eg. PORTS and EPORTS).

As the application user and/or programmer I should not have to know that
some low-level driver talks to one set, and another to some other set,
nor even how many are in any given set.  I really do want one minor
number for all the serial ports in the system.

As the systems programmer in charge of a given system I'm able to lock
down the assignments of given ranges of /dev/ttyN nodes to given
low-level drivers, and I can lock those low-level drivers to given
hardware mappings.

> 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.

/dev/console will always remain mapped to the physical device that will
most likely be the boot console on any given machine architecture.  Sure
if you have a fictional machine where serial ports are only offered in
add-on cards (i.e. no serial ports on the CPU board) and yet where
serial consoles are the sole and/or primary type of console, and you
swap two otherwise identical cards on a type of bus which will cause
their mappings to change, and you don't also swap the cables you've
plugged into them, then maybe on that particular fictional machine, the
console will be on a different terminal when you reboot because the
default might be for it to be port#0 on the card closest to the CPU
card, or something like that.  However I don't know of any such actual
machine where this could happen, and even if there is such a machine
then the loser who swaps the cards without also plugging the console
terminal into the new connector which happens to now be in the right
physical location is getting what he or she deserves since on that
fictional machine the definition of "console"-ness has a particular
well-defined meaning which was ignored.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>