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