Subject: Re: TTY virtualization driver
To: Allen Briggs <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 01/24/2002 13:54:25
On Thu, 24 Jan 2002, Allen Briggs wrote:
> On Thu, Jan 24, 2002 at 04:11:57PM -0500, Lord Isildur wrote:
> > please, whoever proposed these massive changes just to rename a few things
> > in /dev read the man pages for ln and mv!!
> > sorry if this sounds like a flame, but this thread is getting pretty silly!
> I agree--it's getting pretty silly.
> The original proposal was to deal with a situation where, on one
> machine class (Sun workstations & servers), it was deemed reasonable
> to have serial port "A" on the back of the box always map to tty00
> on a fresh, standard install and serial port "B" always map to
> tty01 on the same fresh, standard install.
> Seems reasonable and intuitive to me, but this is complicated by
> the fact that manufacturer switched chipsets at some point, so
> serial A on older workstations is controlled by a different chip
> than later workstations.
> This is not a hard problem to solve, and the person looking at it
> made an extrapolation to say, "if it's useful here, perhaps it's
> useful in general--we have all of these serial devices with different
> names in the standard MAKEDEV script and it's not clear and consistent
> between ports what's where. Maybe I can fix more than just my one
> special case." This also seems reasonable to me (and it's actually
> something that I've thought about in the past), but some of the
> arguments against seem reasonable to me, too.
> In any case, my opinion is that's it would be really good (perhaps
> imperative) that the sparc serial ports be handled in such a way
> that in the generic configuration "A" and "B" are always accessed
> by the same device node. As for the more general case, I've wanted
> the virtualized interface feature before (for both serial and ethernet),
> will probably want it again in the future, but right now I'm not too
> worried about it either way.
I pretty much fully agree with you. The one place I disagree is I'd rather
not see the virtualization for the general case. But for the sparc
on-board serial ports, it makes a lot of sense.