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