Martin Husemann wrote:
> On Sun, Jun 04, 2006 at 07:08:59PM -0700, Garrett D'Amore wrote:
>> Even opaque types have to be stored.
> 
> Maybe, but by whom in this case?
> 
>>  This structure lives inside a
>> binary bit, that can't depend on NetBSD source code, as the binary bit
>> is shared across a bajillion different OS' and even releases of the same OS.
> 
> Yes, but IMHO the design of this binary bit is lacking - it should just pass
> a void *token to all the bus accessor functions (which would be a struct
> ath_softc*) and don't care about details of bus_space.

This was the original choice but was discarded because the hal should
know nothing about the layers above.  The bus+tag mechanism currently in
place was actually done to help *bsd work more efficiently; there's no
need for anything more than a single pointer and most systems only use
one of handle+tag.

> 
> My point is that we should try as hard as possible to avoid such designs
> instead of making them even easier to create.
> 
> The bogus design in this case comes, of course, from (i386) microoptimization.
> On some archs (not sure if it's anything but i386/amd64/xen right now) the
> HAL does not use accessor functions but interprets the bus_space_handle_t
> directly using i386 IO instructions.

This has nothing to do with the binary construction.  You are passing
opaque data through multiple layers of code with the result coming back
through a callback mechanism.  I don't know what Garrett is doing but
the code I gave him adds no overhead except for sparc64 where a struct
cannot be directly passed through the intermediate layers so you must
provide an indirect ref.

Regardless all this is a waste of bandwidth as the overhead of this
stuff is minimal and the time spent doing register read/write operations
is down in the noise.

> 
> Maybe we could try to talk Sam into changing the HAL API for archs with
> accessor functions to simply pass the void *softc, while keeping the current
> API for i386 and friends?

See above.

	Sam