Subject: Re: Proposed extension to bus.h interface
To: Eduardo E. Horvath <thorpej@nas.nasa.gov>
From: Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de>
List: tech-kern
Date: 08/16/1996 09:46:08
Excerpts from netbsd: 15-Aug-96 Re: Proposed extension to b.. Jason
Thorpe@nas.nasa.go (893)
> > Wouldn't bus_io_{alloc,free}() be better as bus_mem_{alloc,free}() with
> > a different chipset tag? All you're doing is allocating from a different
> > address space.
>
> No, because the chipset tag identifies the bus, in the particular case
> I'm thinking about, "ISA", or a particular implementation of "ISA".
> Otherwise, by your suggestion, we'd only have bus_mem_*(), and the
> bus_io_*() functions would be gone completely.
Think of VME bus, there are lots of address spaces (at least the 3
address widths must be separated, BLT must be handled).
How to avoid to write
bus_mem_A{16,24,32}_{SGL,BLT,BLT64}_{alloc,free}() ?
In an ideal world, I would drop the bus_io_*() at all, and
introduce a space patameter to the bus_mem_{map,alloc}* functions.
The only reason for this split seems to be the ability to use
macros for the io on the i386. Somebody investigated the
performance loss caused by replacing the macros by
(indirect) function calls?
best regards
Matthias Drochner