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