How is it different? With the different devices method you have to
reconfigure the driver when doing open(), and with the ioctl method you need
to do that when you do the ioctl(). Btw, what happens when you try to use
both the buffered and the unbuffered device?-)
The only advantage I see in implementing the raw device instead of the ioctl
is that you can use software like "dd" on it without modifying its sources.
But why not implement both? The raw device could be just like the block
device, it would only have the raw behavior as default..
It would be nice to have a finer control of the caching/etc. than
raw/non-raw/O_SYNC though. Imagine telling the kernel that "my access
pattern for this file is linear/completely random/probably around previous
access", or that "don't cache reads, but do read-ahead of 4 MB if possible".
I imagine that xanim/mpg123/etc. would use the last one..
And maybe the kernel wouldn't need to exactly honor that "no caching"
request, it would only mark it as freed memory or something (I don't know
much about mm internals) so if there's lots of free memory around it would
still be cached, but if need arises they will be the *first* pages to go.
-- Did you hear that there's a group of South American Indians that worship the number zero?Is nothing sacred?