[ On Thursday, January 24, 2002 at 13:31:40 (-0800), Jason R Thorpe wrote: ]
> Subject: Re: TTY virtualization driver
>
> So, the idea of having a virtualized TTY layer is nice, but there are
> some real problems with it, the biggest one being naming.

So goes it with /dev/sd* too....  :-)

> 	(1) If you use the autoconfiguration machinery to assign
> 	    virtual names to physical hardware, then you have
> 	    the really annoying problem of spew when you attach
> 	    large multi-port serial adapters, e.g. Cyclades-Z
> 	    boards, which have 16, 32, 48, or 64 ports.

Yeah -- the same thing happens with a large number of SCSI disks too....

But that's easy to deal with -- just don't spew all the noise you don't
need/want to see!  ;-)

For example I'd be happy if kernels without SCSIVERBOSE simply said
something more along the lines of:

	scsibus0: sd0, sd1, sd2, sd3, cd0
	scsibus1: sd4, sd5, sd6, st0, st1, ch0
	scsibus2: sd7, sd8, sd9, sd10, sd11, sd12, sd13, sd14, sd15

Of course it would be nice to still have a way to ask the kernel what
SCSI target/LUN a given /dev/sdN is mapped to.  Such a feature would be
nice to have regardless of what might have been spewed on /dev/console
by the kernel when it booted.....

> 	(2) If you don't use autoconfiguration machinery, then you
> 	    have now put the kernel in charge of device naming policy,
> 	    which is no different than the current situation.

I for one wouldn't suggest that -- at least not without suggesting
a full DEVFS!  ;-)

> 	        But, it's
> 	    actually worse than the current situation, because with the
> 	    current situation, you can still wire down driver instance
> 	    unit numbers using config.

Huh?  What part of my fictional example was so severely flawed?

> 	(3) This is good for "TTY virtualization", but the TTY line
> 	    discipline is only one thing you might be interested in
> 	    hooking up to a serial port driver.  You yourself have
> 	    already had to deal with attaching a non-TTY line discipline
> 	    to a UART driver (Sun keyboard on 16550).  It seems like
> 	    any attempt to virtualize TTY instances should also attempt
> 	    to address this broader problem of picking the appropriate
> 	    default line discipline for a device.

In my fictional example it would be trivial to attach any upper-layer
driver to the low level UART driver -- be it a keyboard driver, a mouse
driver, or a TTY driver.  Calling it a line discipline is probably
misleading since that's only the old-fashioned way of dealing with
different ways to use a UART.

This does of course leave the kernel in control of the upper-layer
driver mappings, at least unless/until there's a mechanism for
controlling them from user-land in a running system.  This won't matter
much for the likes of Sun workstations where the physical places you can
plug a mouse in are limited to those connected to specific UARTs in any
case.

Virtualised TTYs would not have to give up the concept of having special
line disciplines though.  One could still plug a serial mouse into any
serial port on a PC (or any machine) and use it as the system mouse
(assuming we had a generic line discipline for serial mice, and a pseudo
driver for it that could be attached to wsmouse or whatever).

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