>    > * In some weirder cases, you might even have one device mapped in I/O
>    > space, and another one of the same type mapped in memory space, on the
>    > same machine.
> 
>    I can't see this, unless you are defining a device by the driver it
>    uses rather than the actual hardware itself.
> 
> No; I mean the hardware itself.  One could imagine a scenario like
> this:
> 
> * 1 DEPCA card in an ISA slot
> 
> * 1 DEPCA card in an ISA slot, which is connected via a PCI-to-ISA
> bridge that maps I/O space to memory space.
> 
> In both cases, you have the same device, but the method of accessing
> the registers is necessarily different.
> 
> Right now, we don't have any cases of this happening in a single
> machine, but we can have both cases in separate machines.  Do we have
> to use separate drivers for the two, or do we make the DEPCA driver
> know how to talk to both kinds of busses?  That's part of the problem
> I'm addressing.

It seems to me that this is a specific result of a type of I/O space
access pardigm that is definitely bus-associative.

That is, it should be filled in as function pointers in a call struct
that is provided to the driver routine on a device-attach-to-bus basis,
and that attach (device instance) should call via the callback to do
its I/O operations.  The additional overhead is a function call if the
previous reference was an inline and a pointer dereference.

The biggest impact will be on things like SPARC processers, where a
potential exists that if this pushes it over the 4 call boundry, the
entire frame will have to be fushed again, or worse, it will change
the location of a frame push in a timing dependent routine.  It's
arguable that this shouldn't be the case from the perspective that
the interrupt stack and the kernel stacks should be seperate entities.

I think it can be argued that time criticality on a n instruction
count basis is intrinsically bad driver design, and such code would
have to be corrected anyway.  Also, typically SPARC hardware is better
designed than unbuffered PC bus hardware anyway, and will typically
be more tolerant because of buffering and non-ambiguous access in
the hardware programming specs.

I can envision serial cards and similar things being built this way in
the future by people who don't know what they are doing when it comes
to hardware design on PCI.  This could be a problem.

I say burn that bridge when you come to it.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.