How to get a device_t

M. Warner Losh imp at bsdimp.com
Wed Aug 6 18:29:04 PDT 2003


In message: <20030807005810.GG35859 at cicely12.cicely.de>
            Bernd Walter <ticso at cicely12.cicely.de> writes:
: The host bridge is not available yet at probing time of the host bridge.
: What we have is the host bridges parent (nexus) in the calling function.
: Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
: we find it out later.

Don't you mean legacy_pcib_is_host_bridge?  That's where the matching
is done in current right now (well, at least as of my last sync) If
so, passing the host bridge's device down to it would be trivial to
add.  It would also allow other CPUs with builtin host bridges to do
similar tricks to the one that is done for the ELAN.  These sorts of
features have been very common in other CPU families, and there's no
reason to think that there won't be more of them in the x86 family as
time goes on.

I'm not sure that adding it to nexus at this stage of the boot would
truly work.  Since the legacy device has decided to attach, the nexus
bus is already walking through its children.  Adding a child during
that walk strikes me as dangerous, since we have no locking on the
children element of the device_t.  Hmmm, looks I just found a source
of problems in my newbus locking code that might explain some weird
things happening when I enable it....  Thanks for making me go look :-)

Warner



More information about the freebsd-hackers mailing list