Subject: Re: structural bus_space_handles
To: Izumi Tsutsui <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 06/04/2006 21:58:18
Izumi Tsutsui wrote:
> firstname.lastname@example.org wrote:
>> 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. (Making Atheros' "tag" really be a pointer to bus_handle_t
>> instead of a bus_handle_t itself.)
> Do you have any benchmark to measure the performance penalty
> by pointer indirection? I doubt it's measurable.
>> Architecturally this is clean, but
>> it seems a poor choice for performance.
> There is a guideline "only clean code" in src/doc/TODO
> so I don't think you could get consensus at the point.. ;-p
>> Bus handles (or opaque access handles for the Atheros HAL) are currently
>> stored in void *. I cannot change that bit. I'm trying to make it
>> possible to address the problem of making this work well for NetBSD in
>> the normal case (where the types are pointers anyway), while also
>> allowing sparc bogosity to work as well. See above for more explanation.
> I agree that it's sometimes problematic to use non-pointer type
> structure for bus_space_handle_t on implementing real MD drivers,
> but it's worse to introduce some loophole like
> __BUS_SPACE_HANDLE_IS_STRUCT in MI APIs. It's still better
> to define some new API to handle the opaque type as christos said.
> Izumi Tsutsui
I've decided to give up and pay the indirection penalty on all ports
except i386. (i386 uses a different HAL that doesn't suffer the penalty.)
If someone wants "better" performance on non-i386 hardware, then they
can go and fix the ports that insist that handles should be allowed to
be non-ordinal types.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191