Date: Mon, 13 Nov 2000 09:02:17 -0600 From: Robert Lipe <robertlipe@usa.net> To: Mike Smith <msmith@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <20001113090217.Y20018@rjlhome.sco.com> In-Reply-To: <200011130843.eAD8hAF01093@mass.osd.bsdi.com>; from msmith@freebsd.org on Mon, Nov 13, 2000 at 12:43:10AM -0800 References: <20001113004410.W20018@rjlhome.sco.com> <200011130843.eAD8hAF01093@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 > > you doing things this way? [ Answered in separate message. ] > Are the devices you're interested in likely to be attached to by > drivers of their own? Yes. I'm writing the bridge driver. It will then enumerate/bind/attach child devices which are drivers of their own. > Is your driver always going to be in the kernel, or is it liable to be > loaded as a module? I like modules. I think this whole thing would be a numer of modules. > > to avoid the hard-coded major numbers in the cdevsw[] entry that's > > passed? It seems like make_dev() should be able to roam cdevsw, find > > This is what devfs is meant to achieve. Unfortunately at the moment the > major numbers need to be fixed because there's no dynamism in /dev. If If you have devfs (and it means the same to you that it does to other OSes) that would solve the problem nicely. So is devfs something in 4.1.1 or is it future work? If it's here now, can you point me to an example? If it's future work, is that where I should be focusing? > > How is this handled for, say, third-party drivers? > > Typically in the past we've just handed out major numbers to vendors > wanting to ship public drivers, or for in-house stuff just advocated using > the "local" ranges. For a UDI driver, that would be a problem. A UDI driver-writer has no clue where his target device will be running and, indeed, could be running on an OS without a /dev. So we could carve out a pool of b and c major numbers for UDI to then dynamically manage on behalf of the drivers, but that seems tedious. The environment has enough bread crumbs to know of a given driver is an HBA, a NIC, or something else and can set things up appropriately behind the scenes. 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?20001113090217.Y20018>