Kenneth D. Merry wrote:
> On Mon, Nov 13, 2000 at 00:44:10 -0600, Robert Lipe wrote:
> > I have a need to walk the PCI bus, gleaning PCI IDs and other data.
> > (Yes, I know a dozen reasons why to NOT do that.) What I *almost*
> > need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
>
> Well, it might help if we understood a little more about why you want to
> look at all the devices on the PCI bus. There are certainly plenty of
> reasons to do it, but there may be other/better ways to get the
That's fair. I should have expected to "defend" against those dozen
reasons. :-)
> What does your driver do?
It's not a driver as much as driver infrastructure. To measure the
difficulty of porting the UDI Reference Implementation (available source
soon!) I decided to try porting it to an OS that I knew little about.
UDI has a concept somewhat like that expressed in the core BSD bus
enumeration code where you have a bus/bridge driver that enumerates
children (additional busses or cards) which may each enumerate
additional children. It looks like the normal BSD interfaces to the PCI
bus assumes that I am one of those children. This is understandable and
has parallels in UDI-land.
What I really want is to be able to walk the installed/supported busses
for a chance to bind them to UDI drivers. So I don't really want to
replace the existing tree-builder, I'd like to make something somewhat
parallel to it.
Alternately, if there's a standard interface to a system configuration
database that stores this tree, I could walk that table and hand that
information to my bridge driver. UnixWare (resmgr), HP/UX (cdio) , and
AIX (can't recall the name of it) have such interfaces.
> If you do need to get at the data, the easiest thing to do would be to
> un-staticize pci_devq (in pci.c), and include pci/pcivar.h in your program,
> to get the definition for struct pci_devinfo.
I went down that path, but then got sucked into a morass of chained
includes that didn't have an obvious end. It looks like pci_devq
has most of the interesting information that I'm looking for. (Not
suprising since I'm wanting to do with that data pretty much what pci.c
is doing with it...)
> code. If this is a driver you're going to want to ship in source or module
> form,
It is. I'd like the reference implementation to ship in source form.
It currently make extensive use of modules.
> we'll likely need to work out how you're going to do it (i.e. what
> changes will go into the tree), so the module or driver will work when
> it is loaded or compiled.
I'll come up with a set of changes to pci.c that won't nauseate
everyone.
Thanx,
RJL
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
