memcpy() vs. memcpy_fromio()

Paul Gortmaker (gpg109@vger.rutgers.edu)
Mon, 17 Jul 1995 18:44:29 +1000 (EST)


I was thinking about what happens to a routine that (at the
moment) uses memcpy() that can have src (and/or dest) being either a
"real" memory address, or a shared IO memory address of a peripheral
device on the bus. This isn't an issue for the i386, but it will be
for the other architectures that have to do the transfer in some
magic way, due to adding offsets, memory syncs, or whatever.

For example, consider eth_copy_and_sum() which has the simple job
of copying and checksumming from a driver designated pointer into
the data area of a skbuff. It presently uses memcpy() to move the
some (or all) parts of the packet into the skb.

Now, if the driver that calls eth_copy_and_sum() happens to be the
lance driver, then memcpy() is what we want, since the lance has
used DMA to drop the packet into "real" memory.

However, if the same routine is now called by the wd (or any other
shared memory ethercard) then the src pointer is a shared memory
address, and we would want to use memcpy_fromio() so that the required
magic gets performed.

Another example would be csum_partial_copy(), which (for the alpha)
just does a memcpy() -- implicitly assuming that the src (and dest)
lie in "real" memory space. There are probably lots of other examples
as well.

An obvious hack^H^H^H^H fix would be to have the calling driver pass an
additional flag to routines like the above so that they can decide on
whether to use memcpy() or memcpy_{from,to}io(). Not very pretty.

Comments anyone?

Paul.