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 <sys/...>, 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
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message