>> The ath HAL code is bogus in this regard - it has no right to assume
>> anything about the opaque type.
> I disagree.

Fortunately or unfortunately, that is the way the bus-space interface
is defined; it's a matter of fact, not opinion.  That's what it *means*
for a type to be opaque.

> The "general" solution is to make if_ath_pci.c and if_ath_cardbus.c
> store the bus_handle_t in an OS-specific handle, but then that means
> that all architectures get penalized by another level of pointer
> indirection.

That's (part of) the price you pay for using a binary-only HAL that
makes invalid assumptions (like assuming that a bus-space handle can be
stuffed into a void * without loss of information).

> Frankly, I still find the idea of having a structure instead of some
> opaque pointer type (which could be a physical address or a pointer
> to a more complex structure as in sparc64) distasteful.

So, propose a new bus-space implementation for sparc64.  I'm not about
to try to second-guess whoever designed the sparc64 bus-space; I don't
know enough about the architecture.

> But I am not asking NetBSD to change this, only to make it easier to
> tell when a bus_handle_t can be safely cast to a void * or not.

That's easy: it can't.  You may be able to at the moment on some
arches, but you never know when an arch may change its bus-space
implementation and break it - it would be depending on something the
interface definition does not promise.

The HAL layer in question is Just Plain Broken, making invalid
assumptions about the bus-space interface, and while I wouldn't care
for the performance penalty either, it's necessary to kludge around
that brokenness.  One of the prices you pay for using binary-only code.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B