> Whilst looking through the PCI stuff (to determine what the
> 'unconfigured devices' were), I noticed that except for the NCR driver
> and the de enet driver, the stuff was a bit lacking.

Depends on your point of view.  As charles noted, it's not clear how
many of the things that could be added would actually _help_ the
kernel...

In particular, on PCs, the BIOS does cache sizing, device routing,
etc.  It puts the information you need to know (IRQ assignments)
in places that are easy to find.  The things that it doesn't touch
(e.g. cache controller information), you can't safely modify...

You'll note that this _isn't_ the same on the Alpha:  I wrote a driver
that minimally frobs the Intel Saturn I/O controller, etc., because i
need some information it has about interrupt mapping.  Similarly, i
_can_ safely frob the cache controller, etc., and since it's part of a
chipset i have to recognize anyway (not the SIO chip(set?) a different
one...), it costs me little to print out various things about it.

> If one was thinking of either merging the FreeBSD code into
> /sys/dev/pci, what would be the 'cleanest' way to do it?
> (listed in order of quickest/dirtiest to slowest/cleanest):
> 	- 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?

As charles said, this is Wrong.

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

This is unnecessary; why _bother_, especially if it means you need to
do a fair bit of work (which properly interrogating the chips would
be), for almost no useful information.

> 	- 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)?

Actually, it's more likely that I'll end up coming up with some
solution to this, in the near term (which charles probably won't like
8-), because i've been the one doing the most hacking on the PCI code
lately.  I do think that it's annoying to not know what devices are
named what, etc, and it's not that hard to fix...

> Also, whilst I don't have one, Matt Thomas' DEFPA (DEC PCI FDDI driver)
> could be useful, especially since from reading the comments the
> code supports the DEFEI (eisa), and will soon support DEFTA (turbo
> channel). This last one is probably more relevant to port-pmax (we
> have a few 5000/260's with DEFTA's - if only we could run NetBSD
> instead of ULTRIX on them ;) This is probably another of those 'when
> we get around to it' things.

I'm interested in Matt's FDDI driver (and a bunch of other stuff he's
working on; i 'talk' to him via e-mail relatively frequently), but i'd
rather wait on this driver until it's DEFTA-safe...

You see, once the driver works on the DEFTA, it's quite likely that
it'll also work on the DEFPA on the alpha, which is what _I_ care
about.  8-) 



chris