>Right, e.g. replace the normal map/unmap/alloc/free methods with ones
>that do the extra stuff and bookkeeping you need...

>I'd do that by taking an existing bus space tag, copying most of its
>functions, and replacing the few that need to be changed.

Nope. Just the methods which initially create the bus-space tag
and pass it down  to children at match/attach time.

The tacit assumption here is that _all_ implementations do
range-checks when mapping or handing back memory- or io-style handles,
and maintain the permissible ranges internaly as a (base,bound) pair;
and the default tag `constructor' implicitly supplies an
`everything on the bus' case.

This could generalize nicely to (for instance) 16-bit-dma-capable
Unibus devices, or 18-bit capable devices on a 22-bit Qbus...

For CardBus, The need to mixin PCMCIA-style functions is merely
syntactic saccharine :-(

to repeat:

>I'd do that by taking an existing bus space tag, copying most of its
>functions, and replacing the few that need to be changed.

Sure, that'd work too, but if the generic opaque handle object alrady
includes bounds/base pair for each allocatable space, it mostly comes
out in the wash.

anyways, the key point is to add `sub-bus' constructor(s) to the API, no?