The *big* problem I have with that is that the _application_ has to be
aware that DMA will be used to fill the buffer. Thus, you will never
be able to write a driver that implements, for instance, the plain
simple read() and write() system calls using user-space DMA, even
if your hardware is smart enough to do 32-bit addressing and unattended
scatter/gather DMA.
...
Yes, but the _need_ of the application to be aware of the DMA being used
by the driver is a big disadvantage IMHO.
Right ho... and this is something we want to preserve for zero cost
networking transmits.
A unified piece of code which:
1) pages non-present data into a mmap()'d region if necessary
2) marks all the pages read-only for the vma
3) locks each page to keep the swapper and others from mucking
with them
and a piece of code which:
1) Unlocks each page, wakes up people sleeping on them
This would be a nice bit of central infrastructure which I believe
could satisfy both the DMA people (they just need a front end like
what Linus mentioned for the mapping creation) and the high
performance networking geeks like me.
Someone submitted something along these lines some time ago, and it
was mostly based upon the hacks done by Werner and the ATM folks, but
Linus didn't like it as it was a bit crufty. But I could argue that
it looked crufty because it's not 100% trivial to implement this
correctly and clean at the same time in the current Linux mm code.
I also agree with Robert that making part of the DMA interface cater
to ISA 16MB limitations is likely to be totally unused by anyone.
(I'm happy to be shown wrong, if you can think of a useful and
legitimate counterexample, speak up ;-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu