Subject: config(8) vs Brett Lymn :-)
To: None <tech-kern@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 03/04/1997 10:39:13 has a neat little program that walks the autoconf
data structrues via kvm, printing out the device configuration tree.
However, it can't get locators (actually, I think there are hacks now
that get them by groveling dmesg output).

I was thinking about this and realized that config(8) must know a good
deal about locators; after all, it knows that (to use the sun3 port as
an example) "zstty0 at zsc1 channel 0" is valid but "zstty0 at zsc1
addr 0xffe88000 level 3 vect 0x24" is nonsense.  This appears to be due
to lines in files.sun3 that read like

device zsc {channel = -1}

but once the configured kernel is built, this information is
effectively lost - it isn't truly lost, of course, since the various
bus modules know how to interpret their locator vectors, but it's
scattered around the kernel in executable code, not in a form that can
usefully be extracted by something like prtconf.

Now, this probably is not entirely fixable.  However, it occurs to me
that it would be fairly easy to have config generate some
representation of those locator-specification lines for the benefit of
programs like prtconf; the only difficulty then would be actually
extracting the locator values for cloned or otherwise wildcarded
devices.  The kernel-bloat-niks are unlikely to object; even being so
extravagant as to store the information as a verbatim copy of the text
of the "device" lines in question would occupy all of 310 bytes for the
sun3, even less I think for the i386.  Anyone have any reason not to?

					der Mouse

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B