Subject: Re: structural bus_space_handles
To: Garrett D'Amore <email@example.com>
From: Martin Husemann <firstname.lastname@example.org>
Date: 06/05/2006 09:53:38
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.
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.
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?