Subject: Re: structural bus_space_handles
To: None <tech-kern@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 06/05/2006 11:57:11
>> 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
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 email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B