[lkml]   [1998]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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$. ;-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:46    [W:0.165 / U:17.968 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site