> Jason Thorpe writes:
> >On Thu, 15 Aug 1996 12:00:00 -0700 (PDT) 
> > "Eduardo E. Horvath" <eeh@one-o.com> wrote:
> > > 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.
> 
> Exactly.
> 
> As you might be aware, the NCR/Symbios 53C8xx chips support _both_
> memory mapped and io mapped configurations.  It is conceivable that a
> machine with two of these chips installed might have one of them in
> the memory mapped mode and the other in the io mapped mode.
> 
> This is impossible to support with the current interface.
> [ ... ]

Actually, no, it's not impossible, it's just currently not done with
the current driver.  Some would say that the driver is broken.


In my original implementation of all of this code, i implemented one,
unified set of macro calls, with I/O and memory space done as one
address space.  As previously noted, that was shot down.  For some
speed-critical drivers, like the serial drivers, i can understand why
you may want to have everything in-line.  However, it's not clear
that doing a function call (in addition to the I/O port access) would
make much of a difference.  I certainly didn't try to measure it,
because it would have made no difference, since the door had already
been closed on a "unified" scheme.


On the Alpha, everything is memory mapped, but pretty much everything
requires special little hacks, so one set of macros would make sense
and be easier to implement.  On other machine which do memory mapping
of I/O space, the same could probably be said.


In some ways, the current scheme is ... stupid.  For instance, what
exactly is "I/O space" on TurboChannel?  (Hint: i've got a bunch of
stubs that all call panic...)  One shouldn't have to implement
'spaces' which don't exist, and with this scheme, unless you
just don't bother to fill in the pointers, you have to.


The existing scheme looks like it does, essentially, for i386
performance.  Because of the split in the spaces, as others have
noted, it's hard to do things like proper support for bridged busses,
it's hard to do support for busses with more spaces than
currently are named, and it's hard to write drivers which support
choosing between memory and I/O accesses at run-time.

I don't particularly love the existing interface, but it's more or
less what _I_ had to do to get something accepted, so that i wouldn't
have to forever maintain seperate copies of drivers.


cgd