[ On Thursday, January 24, 2002 at 18:57:48 (-0500), der Mouse wrote: ]
> Subject: Re: TTY virtualization driver
>
> > If I pull out a cyclades card and plug in a lava card I've got to do
> > any number of renames, either in /dev (can you spell "major mess"?),
> > or in every related config file (eg. /etc/ttys, /etc/remote,
> > /etc/uucp/Devices, etc.)
> 
> Whereas in your scheme, you have to build a whole new kernel to get
> tty44-tty51 nailed to boca2 instead of cy1.  I'd rather do a handful of
> renames in /dev than I would build a new kernel.

Huh?  I'm implying above that I've only one card.  In "my" scheme you
would not rename anything or rebuild anything.  (It's not really "my"
scheme -- I'm just defending the idea of a generic TTY driver and
expanding on how it really isn't anything new, just a more elegant
implementation of what we almost already have.)

I'd have /dev/tty02 - /dev/tty10 for any 8-port card (assuming two
serial ports are already on the CPU board and that they are either
hard-wired by default or that they would always be attached first).

In fact for ISA (and perhaps PCI) cards with NS8250/NS16550 compatible
UARTS that's what I have today without any new driver layer because as
it so happens all all those compatible chips that are controlled by the
sys/dev/com.c driver, with the specific differences handled by low-level
board-specific drivers that the autoconf machinery maps the com*
instances to (and of course on most NetBSD ports the com(4) driver is
mapped to /dev/tty??).

The same could happen for a machine with alternative Zilog 8530
multi-port implmentations, if zstty(4) were expanded a bit.

A generic TTY virtualisation layer simply merges these two existing
ideas so that one upper-layer TTY driver could be mapped any type of
UART on any type of board on any type of bus, making /dev/tty?? generic
across all ports and all hardware.

> > Yes one can have a scheme where one manually manages the mapping of
> > any number of /dev/tty* names across any number of device major,minor
> > number sets, but that way lies insanity
> 
> Every scheme I've seen you propose has you managing that mapping
> manually; it's just that you prefer to do it in the kernel config file
> instead of in /dev.

I think you misunderstand.

I provided an example of hard-coded kernel config mappings simply to
illustrate that one need not have /dev/tty?? mappings move about when
hardware is changed in ways that would have the default autoconfig
machinery attach the hardware in different ways.  By default the
attachments would be done in the way the driver authors and NetBSD
maintainers defined them to be done, just as I suggested in the first
part of my example.

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