Subject: Re: tty device names for Cyclades Z
To: Allen Briggs <briggs@ninthwonder.com>
From: Nathan J. Williams <nathanw@MIT.EDU>
List: tech-kern
Date: 06/03/2000 16:14:25
<briggs@ninthwonder.com> (Allen Briggs) writes:

> 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:

This is sort of doable; I have parts of it written (in the form of a
tool that prints what devices and attachments are configured into a
kernel).

> # 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)

The problem is that some of this information is only generated at
device attach time and not preserved (at least not in this form). For
example, "ns16550a, working fifo" is known to the driver but there's
no code to convert the internal rep to that string except in the
attach routine. As another example, the PCI device and function
numbers where a device is found are not generally preserved (some
devices stash the machine-dependant pcitag_t in their softc, but that
doesn't help a generic device-tree walker). 

        - Nathan

> 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.

That was my motivation, sort of, until I ran into the above problem
and decided I wasn't up to redesigning the entire autoconfig
mechanisim to fix it :)

> 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().

Especially if sysctl() sucked less. I still think Solaris's ndd model
is pretty good in this regard (but that's Yet Another thread).

        - Nathan