From owner-freebsd-hackers Mon Nov 13 6:50:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 4394237B4E5 for ; Mon, 13 Nov 2000 06:50:24 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id IAA23535; Mon, 13 Nov 2000 08:51:37 -0600 (CST) Date: Mon, 13 Nov 2000 08:51:37 -0600 From: Robert Lipe To: "Kenneth D. Merry" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <20001113085137.X20018@rjlhome.sco.com> References: <20001113004410.W20018@rjlhome.sco.com> <20001112235932.A63657@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001112235932.A63657@panzer.kdm.org>; from ken@kdm.org on Sun, Nov 12, 2000 at 11:59:32PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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