It also appears that the FreeBSD code does some in-depth probing of
   the cache DRAM controller to print out various info that, whilst not
   important, looks interesting to say the least, and would mean more
   pretty stuff on boot :)

I *strongly* object to this.  It strikes me as very pointless to bloat
the kernel with extra code for every cache controller and host bridge,
for the sole purpose of printing out info that most people won't even
understand or care about.  (And indeed their `solution' has ended up
only working on a few chips.)

On the other hand, it might be reasonable to make a standalone
(i.e. bootable) program that probes the PCI hardware more thoroughly,
as well as a standalone memory testing program.

	   - plonk the code into pcisupport.c (or whatever) and just
	   directly code the probes into the pciattach stuff, totally
	   bypassing the 'clean' method used by ncr.c & if_de.c?

That is definitely not acceptable.

	   - implement the devices as separate devices to probe (with
	   their own files)? This seems orthagonal, and with correct
	   dependancies in files.pci of each file to pci.c (such as
	   the 48[34]8086 support)

That would work, but what's the point of attaching a `device' that you
don't know what to do with?

	   - wait for mycroft to get some free time (Ha! I bet it's
	   as mythical for him as it is for me :) so it gets done in
	   the One True NetBSD way (clean, KNF, etc)?

My inclination is to *only* modify the attach code to decode the
`class' identifier into some more readable form.