This is going outside the scope of the tty discussion (although the tty
example might make a good case study / prototype), though.

On Fri, Jun 02, 2000 at 02:47:40PM -0700, Chris G. Demetriou wrote:
> And, if you're gonna go there (and i'm not saying we should 8-)...
> why should ethernet interfaces be different?

They probably shouldn't.  I thought about that after I sent the mail.
There are several other examples of devices that should probably have
a common user/admin interface.  As you point out, there is usually
no reason for IDE disks and SCSI disks to be distinguishable from a
user's perspective.

It would be nice to have a tool that could walk the configuration tree
at run-time and show the "family tree" for each device, for example:

# devshow /dev/sd0
sd0 at scsibus0 target 3 lun 0: <SEAGATE, ST11200N SUN1.05, 9500> SCSI2 0/direct fixed
scsibus0 at adv0: 8 targets, 8 luns per target
adv0 at pci0 dev 8 function 0: AdvanSys ABP-9xxUA SCSI adapter
pci0 at mainbus0 bus 0: configuration mode 1
mainbus0 (root)
# devshow /dev/com0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
isa0 at pcib0
pcib0 at pci0 dev 7 function 0
pci0 at mainbus0 bus 0: configuration mode 1
mainbus0 (root)

Actually, it would be nice to have this as an option to a device
"browser" application that could feed changes, hardwiring, etc.,
back into a kernel configuration file.

On Fri, Jun 02, 2000 at 09:57:44PM -0400, Nathan J. Williams wrote:
> I buy this. It's good for support purposes, in that it makes the
> configuration of simple systems much easier to guess. "you have one
> ethernet card? ifconfig eth0." 

Which also makes tutorials and documentation somewhat easier.  I don't
see that it affects large sites adversely, either--how many people use
different ethernet devices just so that they have different device names
and can tell them apart that way?

> > actually, there's probably an argument that read/write disks,
> > i.e. 'sd' and friends, should be indistinguishable from IDE (and
> > perhaps other) disks, too...
> Though you then need to integreate the various frobbing tools for
> different back-ends (scsictl, atactl), along with some way to figure
> out what the appropriate set of frobs is. We don't have good prior art
> here (see the disaster of tools that is *ctl and *config).

True.  It would be really nice to be able to clean those up, anyway, but
we do need some new work in that area.  Probably some API for the devices
to publish capability and interface information for the frobbing tools.
Presumably, the tools could get at the information through ioctl() or
sysctl().

-allen