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]"