Messages in this thread | | | Date | Sun, 13 Dec 1998 14:26:19 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: PATCH: Raw device IO for 2.1.131 |
| |
On Sat, 12 Dec 1998, Linus Torvalds wrote:
> So I want to be able to do things like frame capture (into a _file_, not a > partition) etc, and there I think something like sendfile() is the answer > (well, "copyfd()", whatever). And there I also think that we currently > would do fairly badly on the write-out part due to the known problems with > buffer cache behaviour under certain circumstances. But basically I still > see absolutely no reason for supporting raw devices per se.
You may forget Linux/Unix O/Ses legacies for just a minute and think of the following:
1) Direct I/Os from user-land. Means that the O/S will try to DMA directly from/to user buffers if it is possible.
2) _Real_ asynchronous I/Os. Means that the kernel tries to start concurrently the IOs if it is possible and notifies user of IO completions asynchronously.
Now imagine that these semantics also apply to regular files. There is no reason they won't, in theory. Then, optimizations that are possible from kernel-land caching strategy are also implementable from user-land, with obviously some overhead that can be avoided when implemented in the kernel.
Using Direct I/Os from user-land synchronously is indeed very bad for streaming since everything will rely on disk write caching and prefetching ability. But by combining direct IOs with an asynchonous I/O completion mechanism, applications are able to implement kind of read-ahead and/or write coalescence algorithms as needed.
Just my 0,02 Euro which is a little more than 0.02$. ;-)
Regards, Gerard.
- 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/
| |