On Thu, Jan 24, 2002 at 07:59:31PM -0500, Greg A. Woods wrote:

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

Ok.

So what happens when you plop another 8-port card in there?

Let's say you plop it into the next PCI slot on your mainboard.  Let's
say that that PCI slot happens to have a lower device number (this is
pretty common).  Now suddenly you have:

	tty00		on-board
	tty01		on-board
	tty02-tty09	new board
	tty10-tty17	previously existing board

So, if you want to nail down all your unit numbers, you still have to
build a new kernel to nail them down.

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

"Most ports"?  On several, it's called "/dev/ttyC*".

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

The zstty thing exists because, on Suns, the 2 of the ports provided by
one of the 8530s is not a serial port from the user perspective, but
rather the interface used for the Sun keyboard and mouse.  The keyboard
and mouse probably should have been done as line disciplines, rather than
as a separate non-TTY device.  If it had been done that way, then it
would have been easier to support sparc64 systems that have 16550 serial
ports for the Sun keyboard.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>