Subject: Re: TTY virtualization driver
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 01/24/2002 12:36:25
On Thu, 24 Jan 2002, Greg A. Woods wrote:

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

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.

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

Fear mongering?

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

Yes, but the value of this doesn't mean that we should dynamically assign
tty numbers. :-)

> FYI /dev/console is already a virtual driver.

So? /dev/console is a case where that virtualization makes sense. That
doesn't mean that we should virtualize everything. :-)

Take care,

Bill