Subject: Re: TTY virtualization driver
To: NetBSD Kernel Technical Discussion List <>
From: Greg A. Woods <>
List: tech-kern
Date: 01/24/2002 15:20:31
[ On Thursday, January 24, 2002 at 11:29:30 (-0800), Greywolf wrote: ]
> Subject: Re: TTY virtualization driver
> This is coming down to a matter of opinion.  In the end, as always, it's
> going to boil down to whose opinion is technically sound and whose will
> be implemented.  There is no historical data to show that these two
> coincide on a regular basis.

Hmmm... if this were not a technically sound idea it would not have
already begun to permeate NetBSD.  Have you not been paying attention to
the other examples?

> At least hitherto it has lived in a world in which it could create its
> own sanity.  Dynamic (re)assignment on new hardware violates the
> PoLS in a large way, especially for terminal connections.  "Mmmmyeah,
> I think I'll run the getty out the line that's hardwired to the other
> system's console today."
> No, thank you.

Sorry but you're already left way back in the dust.  Your fear mongering
(and fear mongering is exactly what you're doing, whether you know it
consiously or not) in this case is futile.

Many people, including (if I'm not drastically mistaken) the very
inventors of the *BSD kernel autoconfiguration mechanisms, are of the
firm belief that automatic detection and attachment of new hardware
fulfills the PoLS in the most succinct way possible.  You add new
hardware and the kernel detects it and attaches it in the most logical
way it knows given the parameters it was itself configured with.

FYI /dev/console is already a virtual driver.

If you don't want your /dev/ttyNN nodes slipping around to different
serial port assignments when hardware changes are made then you will
simply hard-wire their assignments, just as I do today with my SCSI
disks and the /dev/sdNZ nodes.

								Greg A. Woods

+1 416 218-0098;  <>;  <>;  <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>