I disagree.
readb() and friends should be used for AT LEAST PC-style memory mapped
accesses. Whether it should be used for anything else is not 100% clear.
If you have a different bus, you might decide that the readb/writeb
interface really isn't very good, and you want to do something else. You
may, quite validly, decide that you're better off having a "vme_readb()"
or similar interface that takes slightly different parameters. For all I
know, it might have different synchronization behaviour from a normal
PC-like memory-mapped area.
Why do people think that everything has to be so damn generic? If
somethins is specific to some special kind of bus, then you SHOULD use a
specialized access. You shouldn't try to make everything look the same.
That just leads to cludges and backwards compatibility problems wen
something new comes along.
The fact is, that these days the PCI-like derivatives (and predecessors)
are just so popular even among non-PC's that I consider PCI to be the
major interface. That does NOT mean that it should be the only interface,
and it does NOT mean that all other buses should use "iomem" and "ioport".
> But now Linus claims all these things are for PCI only?? What should I use
> for other busses then?? Don't forget there are many drivers that work for
> the same device connected to different busses.
When that happens, it is only the driver that can know what the
difference is. If there is a VME and PCI version of the same card, you
should make that explicit in the driver sources. Because there WILL be
other differences anyway - how you find the thing, how you initialize it,
etc etc. So then the driver should be ready and willing to do separate
initialization.
> - Linus says I/O space has 64K entries, and memory space has 4GB entries.
> In the mean time 32 bit I/O space showed up in the thread. What about
> busses with a 64-bit memory space (64-bit PCI)?
We'll expand things AS THE NEED ARISES.
It's already been shown that the ioport limit is only 64k on a PC, but on
a PC that is a HARD limit right now.
For 64-bit PCI we'll extend it as needed. Right now you cannot access >32
bits on a 32-bit machine anyway with the current Linux setup. On an alpha,
you can, and the resource code is there already (we'll just up the limit
the same way as for ioports).
The thing is: trying to be too generic is EVIL. It's stupid, it results in
slower code, and it results in more bugs.
> - Instead of `peanuts', I'd vote for `io' and `memory' :-)
> Calling it `PCI' is confusing, since there are machines without PCI
> busses, and machines with PCI and other (SBUS, Zorro) busses in one box.
And EXACTLY because there are machines with PCI and other buses, there
should be a CLEAR delineation of the two. They should NOT be the same
resource. If your SBUS subsystem tries to look too much like PCI, that's
probably a mistake in itself.
And trying to impose any SBUS behaviour on the PCI resource allocation is
just NOT going to happen. Ever. Either you make it look exactly like PCI
from a device driver standpoint (at which point you might as well just
admit to the fact that it IS PCI as far as Linux is concerned, it just has
slightly different connectors - and you shouldn't complain about PCI-only
issues), OR you make it a primary bus in its own right, with its own
resource allocation and with its own access functions and with its own
identification functions.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/