Subject: Re: tty device names for Cyclades Z
To: Nathan J. Williams <nathanw@MIT.EDU>
From: Brett Lymn <>
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

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

      pchb0 (device = 0, function = 0)
      pcib0 (device = 1, function = 0)
            com0 (irq = 4, port = 0x3f8)
            com1 (irq = 3, port = 0x2f8)
            pckbc0 (port = 0x60)
            pcppi0 (port = 0x61)
            npx0 (port = 0xf0)
            fdc0 (irq = 6, port = 0x3f0, drq = 2)
               fd0 (drive = 0)
            pcic0 (port = 0x3e0, iomem = 0xd0000)
                  wi0 (port = 0x340, function = 832)
      pciide0 (device = 1, function = 1)
            cd1 (drive = 0)
      de0 (device = 9, function = 0)
      vga1 (device = 10, function = 0)
      ahc0 (device = 13, function = 0)
            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