Date: Mon, 13 Nov 2000 08:51:37 -0600 From: Robert Lipe <robertlipe@usa.net> To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <20001113085137.X20018@rjlhome.sco.com> In-Reply-To: <20001112235932.A63657@panzer.kdm.org>; from ken@kdm.org on Sun, Nov 12, 2000 at 11:59:32PM -0700 References: <20001113004410.W20018@rjlhome.sco.com> <20001112235932.A63657@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001113085137.X20018>