Subject: Re: TTY virtualization driver
To: None <>
From: Greg A. Woods <>
List: tech-kern
Date: 01/24/2002 18:10:07
[ On Wednesday, January 23, 2002 at 02:36:58 (-0500), der Mouse wrote: ]
> Subject: Re: TTY virtualization driver
> _What_ tty allocation and assignment algorithms?  I don't know of _any_
> case where real hardware ttys are "allocated and assigned" by software;

terminal servers, UUCP, tip, /etc/ttys, etc.  Anywhere you might give a
list of /dev/ names to specify a set of serial ports.....

> > I personally think there's more benefit to doing this kind of name
> > mapping in ttys, network interfaces (at least per physical layer
> > type), audio interfaces, and anything else that's more likely to be
> > used directly by ordinary (non-superuser) users,
> Hm.  I can't see that benefit, unless you just happen to like it
> aesthetically.  Could you explain in a bit more detail?

Things (device nodes) which are used uniformly by one or more
applications, regardless of how they are implemented in hardware, and
regardless of what particular device driver and thus major number used
to communicate with them, should really have a uniform naming
convention, even if there's only ever two of them in a given system.

The most elegant way to give such things a uniform naming convention (at
least in *BSD systems with the current kernel autoconfiguration
mechanisms) is to give them one major number and to give them an
upper-layer device driver that the kernel can map to arbitrary similar
low-level hardware device drivers.

We have this now for many classes of similar devices, to varying degrees
of completeness.  Adding an upper-layer TTY driver so that all serial
ports can be mapped arbitrarily to it is just another step in the same
direction.  Many people have expressed even stronger desire to do the
same for Ethernet interfaces too, and to do this right I think it should
really be all IP-capable network interfaces, not just "ethernet" ones.

								Greg A. Woods

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