Subject: Re: tty device names for Cyclades Z
To: Nathan J. Williams <nathanw@MIT.EDU>
From: Brett Lymn <blymn@baesystems.com.au>
List: tech-kern
Date: 06/04/2000 18:58:28
According to Nathan J. Williams:
>
>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).
>
This _is_ doable. I have already done it. Viz:
[blymn@siren] prtconf
System is a i386 architecture on a Intel Pentium Pro (686-class)
with 100270080 bytes of physical memory, 96313344 bytes is
non-kernel memory
mainbus0
pci0
pchb0 (device = 0, function = 0)
pcib0 (device = 1, function = 0)
isa0
com0 (irq = 4, port = 0x3f8)
com1 (irq = 3, port = 0x2f8)
pckbc0 (port = 0x60)
pckbd0
wskbd0
pmsi0
wsmouse0
pcppi0 (port = 0x61)
sysbeep0
npx0 (port = 0xf0)
fdc0 (irq = 6, port = 0x3f0, drq = 2)
fd0 (drive = 0)
pcic0 (port = 0x3e0, iomem = 0xd0000)
pcmcia0
pcmcia1
wi0 (port = 0x340, function = 832)
pciide0 (device = 1, function = 1)
atapibus0
cd1 (drive = 0)
de0 (device = 9, function = 0)
vga1 (device = 10, function = 0)
wsdisplay0
ahc0 (device = 13, function = 0)
scsibus0
sd0 (lun = 0)
cd0 (lun = 0)
I _really_ should work out how to create a package for it....
>
>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).
>
Yes, about the only thing you can do is parse the dmesg output for
locators which is not nice. At least in -current a copy of the boot
dmesg is put into /var/run so you don't lose the locator info.
>> 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 :)
>
Myself and David Forbes (creator of the custom kernel grinder) have
been looking at doing this on and off for a while. We both had first
passes at it independently and now have joined up to try and put
together something better.
--
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================