Subject: Re: TTY virtualization driver
To: Lord Isildur <>
From: Allen Briggs <>
List: tech-kern
Date: 01/24/2002 16:40:07
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.


 Allen Briggs               Quality NetBSD CDs, Sales, Support, Service
NetBSD dev. for _your_ Alpha, ARM, M68K, MIPS, PowerPC, SH3, Sparc, x86, etc...