>>    In order to really do this properly, the m68k ports should probably 
>>    implement the <machine/bus.h> interface designed by cgd...then, it might 
>>    even be possible to share things like the 8390 driver with the i386 port.
>..
>> 
>> No.  On the i386, the cards are mapped through I/O space; on the
>> others, they're mapped in memory space.  Chris's interface does not
>> deal with such conflicts.
>
>Nor can it, without imposing unnecessary speed penalties on devices
>that don't need to deal with that case.
>
>i figure, if you're writing a device that has to deal with that case,
>and you _really_ _really_ _really_ want it to work with both memory
>and I/O spaces, you'll do one of two things:
>	(1) #ifdef, which is plenty fast, but will only let you
>	    use one method, in any given kernel, or
>	(2) run-time test a flag, which is slower, but which will
>	    let you do whatever you want.

I don't see why you can't have your cake and eat it too.  On architectures
that don't have a PIO capability, why not make the *io functions a
compatibility interface that does memory references.  Since you have io
setup and teardown functions all the overhead of doing this can be done at
probe time without any run-time test.  If you really want to support both
memory mapped and PIO functionality in a particular driver, sure, that
driver author has to jump through hoops, but in the general case of a
driver that is structured to perform PIO but can work on architectures that
use memory mapped devices instead, you can achieve MI without a speed
penalty or a forest of #ifdefs in the driver code.

Or did I misunderstand the problem in that there is an I/O space in the
m68k and that you want to use memory mapping instead.

>You will note that I/O and memory operations do have the same set of
>arguments, etc., though on different architectures their arguments'
>types may be different.

Hmmm.  Why would their argument types change?  I thought you provided
a full set of 1,2,4,8 byte operations and that only the opaque bus_t
type and the size of the offset type might change.  You should be able
to export a common interface to the device driver.

>chris

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================