Re: Properly managing sub-allocations

John Baldwin <[email protected]> Mon, 2 Oct 2006 16:20:43 -0400
Newsgroups gmane.os.freebsd.devel.new-bus
Message-ID <[email protected]>
On Monday 02 October 2006 15:42, M. Warner Losh wrote:
> In message: <[email protected]>
>             John Baldwin <[email protected]> writes:
> : > However, this may break some existing drivers that allocate a BAR,
> : > peek at its type and then either activate it or allocate another
> : > BAR...  The TAG is valid, but the handle isn't.
> : 
> : They generally peak at the BAR register itself though, not the value of 
> : rman_get_bustag() though, right?
> 
> Some do, some get the resource and look at it.  There's a lot of
> variance here.  Do you put knowledge of how to decode PCI bars into
> every driver, or do you let the pci bus take care of it?  Since the
> knowledge is nearly trivial, different people decide differenly.  It
> is still a technique that has been used, and you'll need to be careful
> to make sure you don't break anything.  After all, 0 is a valid I/O
> tag and it is also the default value...

Err, how can code examine the actual bus tag value of a non-active resource?  
By definition it's set an opaque MD value.  You can't compare it against 
SYS_RES_MEMORY for example.  On i386 systems it happens to be an int, on some 
other systems (alpha maybe?) I think it can be a pointer to a structure of 
function pointers for the different bus space operations.  I don't think any 
MI code should ever be examining the bus tag or handle except to pass them as 
opaque parameters to bus_space_*().

-- 
John Baldwin
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "[email protected]"