Date: Mon, 13 Nov 2000 10:26:42 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Robert Lipe <robertlipe@usa.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <20001113102641.B66956@panzer.kdm.org> In-Reply-To: <20001113085137.X20018@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Nov 13, 2000 at 08:51:37AM -0600 References: <20001113004410.W20018@rjlhome.sco.com> <20001112235932.A63657@panzer.kdm.org> <20001113085137.X20018@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 13, 2000 at 08:51:37 -0600, Robert Lipe wrote: > Kenneth D. Merry wrote: > > 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. Ahh. > 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. That is probably the direction you want to go in. We've got a device infrastructure already (new-bus), which is probably what you want to use. If you probed and attached UDI devices apart from new-bus, you'll probably run into all sorts of resource conflicts. (cards with two drivers attached and stepping on each other...) Unfortunately I don't know much about new-bus, so I can't tell you how easy it would be to do what you want to do with it. (There are other folks on this list who do know, though.) I do know that we have the concept of probe priorities, so you could probably set up UDI to probe at a higher priority than the default system drivers, and therefore attach instead of the default FreeBSD driver for a given piece of harware. > > 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...) Yep. That's probably not the way to go for what you're doing, though. > > 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. Cool, it'll be interesting to see the source. Ken -- Kenneth Merry ken@kdm.org 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?20001113102641.B66956>