[ On Thursday, January 24, 2002 at 16:05:03 (-0800), Bill Studenmund wrote: ]
> Subject: Re: TTY virtualization driver
>
> Not quite. While it's a similar issue, differences in how systems usually
> are set up make (IMHO) sd's attaching wherever make more sense than having
> tty's attach wherever (the "virtual" layer).

I guess that's where our opinions differ.  See below.

> One big difference is that when you have a tty, you really have a plug you
> can hook something into, whereas when you have a disk (sd or wd) you have
> a disk plugged into a controller and configured to appear at a specific
> address. For ttys, the drivers don't know if there's something out there,
> just that there's a plug.
> 
> So when you plug in a serial controller with 16 ports, you have 16 tty
> ports. But when you plug in a wide scsi controller (which can support 16
> targets), you don't necessarily have 15 other drives out there. You can
> have tape drives, scanners, and ethernet devices at these targets too,
> *AND* the scsi controller can tell what they are. So we know what's there.

Indeed -- for "virtual" TTYs you would always get all of the minor
numbers attached and configured since all the UARTS (or their conceptual
components) hopefully always exist regardless whether anything's plugged
into their physical connectors or not, whereas with bus-attached devices
like SCSI disks you only get the minor numbers attached for the disks
that are present on the bus at the time you probe it.  There are no
holes in the disk attachments, meaning that the bus and sub-unit
addresses have no fixed relationship to the minor numbers and if holes
in the address space are used up by new devices since the last probe
then by default the minor numbers for the following units change,
perhaps causing their mappings in /etc/fstab to go wrong.

> That's a big difference. So it make sense (to me) that how we handle sd*
> devices is different (and IMHO should stay different) from how we handle
> ttys.

That's why I think a virtual layer for TTYs is even more useful than it
is for SCSI disks.

I'd rather always have holes in the disks attachments, and all the
possible names enumerated in /dev so that /dev/sdc0t0l0 is always the
disk that would be found on SCSI controller number zero, target number
zero, LUN zero, regardless of whether it was there when bus#0 was
probed.  (Of course it gets trickier when you have hot-swap controllers! :-)

In other words I'd rather trade off the virtual sd* mapping for tty*
mapping!

That's why I said such virtual mapping is even more important for device
types that end users are more likely to use directly, such as exactly
TTYs and audio devices, and so on.

That's why I always hard-wire all my devices in production machines,
even the SCSI disks, right down to their LUNs even though most can only
be found on LUN#0.  I don't want them moving around.  As I mentioned
before I do though keep wild-card entries there so that the kernel will
still at least boot and find all the possible hardware even if it moves
around or new stuff is added.  Such are the pros and cons of the *BSD
kernel autoconfiguration machinery.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>