From owner-freebsd-hackers Sun Nov 12 22:59:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D68AC37B479 for ; Sun, 12 Nov 2000 22:59:35 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA63724; Sun, 12 Nov 2000 23:59:32 -0700 (MST) (envelope-from ken) Date: Sun, 12 Nov 2000 23:59:32 -0700 From: "Kenneth D. Merry" To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <20001112235932.A63657@panzer.kdm.org> References: <20001113004410.W20018@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001113004410.W20018@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Nov 13, 2000 at 12:44:10AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 13, 2000 at 00:44:10 -0600, Robert Lipe wrote: > I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with > 4.1.1 on IA32 and need help understanding the ways of your world. :-) > I'd like my project to look like a "normal" driver and use supported > interfaces, but I'll patch the core code if I need to. > > 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 > that this is a private data structure (static, lots of dependencies on > private headers not in , etc) and therefore unavailable. I > considered calling the ioctl code myself from withing my driver, but > that seems too weird. I thought about shipping the data to myself by > way of user-space (daemon does an ioctl ('pciconf -l'ish) to PCI driver, > turns around and hands data to me on an ioctl) but that sounds like an > application to be punished. > > Is there a "normal" way for a conforming driver to walk the busses, > pluck out bus number, slot number, device id, subsystem id, and all that > traditional stuff, or do I just need to carve up pci.c and build my own > interface to do it? 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 functionality you need. (I've done it from userland, FWIW. I also wrote the current PCIOCGETCONF code.) What does your driver do? 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. If this is an embedded-type project that's going to involve shipping already-compiled code, I wouldn't worry too much about modifying the PCI code. If this is a driver you're going to want to ship in source or module form, 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. [ ...major numbers for loadable devices... ] Someone who knows more about modules can answer that one... Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message