Subject: Re: m68k comman part (was Re: mips ports ...)
To: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
From: Justin T. Gibbs <email@example.com>
Date: 03/21/1996 08:08:05
>> 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.
Justin T. Gibbs
FreeBSD: Turning PCs into workstations