Date: Mon, 13 Nov 2000 22:43:08 -0800 From: Mike Smith <msmith@freebsd.org> To: Robert Lipe <robertlipe@usa.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pci bus enumeration & cdevsw indexing Message-ID: <200011140643.eAE6h8F00774@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 13 Nov 2000 08:51:37 CST." <20001113085137.X20018@rjlhome.sco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Aha! I've been waiting for this since February or so, which was the last
time anyone mentioned that the UDI reference implementation was going to
go public. 8)
> 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.
Unfortunately for UDI implementation, the only real way to do this
"right" is going to be by merging the two infrastructures, ie. making it
possible for UDI drivers to attach to newbus busses (and vice-versa,
although that is probably asking a bit much).
> 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.
Don't. Shim the UDI drivers so that they look like "normal" newbus
devices. Trying to have two sets of infrastructure "owning" the same bus/
resource domain is just going to be ugly.
Alternatively, if you really want to use the UDI bus infrastructure,
you'll have to merge the two fairly intimately.
A third approach would be to discard the newbus code and work out how to
shim existing FreeBSD drivers to live under the UDI infrastructure.
Given the way that newbus works, this might not be all that easy (eg.
there are cases where drivers make valid assumptions about the tree above
them which would be invalidated by this).
> 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.
One thing you could do, if you only care (for now) about unattached PCI
devices, is to look at the way that PCI nomatch is handled, and pass
these devices off to the UDI probe/attach handler. Resources for these
devices can be managed using the normal bus_*_resource interface.
> > If you do need to get at the data, the easiest thing to do would be to
> > 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.
That's not an unreasonable thing to do. Note that every time you load a
device module the system performs a complete bus rescan, so the nomatch
handler is called for every device that hasn't already been claimed.
If you want to discuss this in more detail, please do. Note also that
depending on your NDA circumstances I may already be in a situation where
it would be easy for you to discuss some of this material offline. I'm
pretty familiar with the way that newbus and the BSD PCI code works, just not
with the innards of the UDI reference implementation.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
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?200011140643.eAE6h8F00774>