Subject: Re: structural bus_space_handles
To: Martin Husemann <>
From: Garrett D'Amore <>
List: tech-kern
Date: 06/05/2006 08:15:37
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.

That's what it does *now*.  The problem is that the current driver (not
binary) design was using the void * token to store the bus handle
directly.  I've changed that now, but it means some archs will suffer an
extra indirect reference when doing register access for Atheros boards.
> 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.

Yes, that's true for i386.

> 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?

He passes a void * token (two actually, one for the tag and one for the
handle) now.

The point was that cleaning this up required all architectures to get an
extra indirect access, whereas only sparc truly needs it.

    -- Garrett
> Martin

Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134  Fax: 951 325-2191