---------- Forwarded message ----------
Date: Sat, 10 Jan 1998 19:11:55 -0800 (PST)
From: Simon Shapiro <shimon@simon-shapiro.org>
To: Michael Neuffer <neuffer@goofy.zdv.Uni-Mainz.de>
Cc: Simon Shapiro <shimon@i-connect.net>
Subject: Re: lack of raw disk devices (fwd)
The need for raw devices does not come from this feature, or that feature.
It comes from the simple realization that, at times, user applications may
want to access storage in a manner not concieved by the O/S authors at the
moment. They also want to do so without waiting for the blessing of the
O/S author, nor are they willing to wait for this or that feature to become
available.
The core of the problem in Linux, in this regard, is that some developers
cannot concieve that a user application may want to access data in a manner
not approved, nor thought of by themselves.
This is not to say that in an ideal world, such access is a ``good thing''.
It is not.
Going into this example and that, is fruitless. Last time I brought this
up, Linus reply was ``Well, they should re-write their database engine
then.'' Actually his words were much less polite than that.
I do not work for Oracle anymore, nor do I represent Informix. I will
tell you, though, that this attitude is silly at best. My reply to that
comment was to switch from Linux to FreeBSD.
BTW, this you can happily forward to your mailing lists. you know my
opinion in this matter already...
On 11-Jan-98 Michael Neuffer wrote:
> ---------- Forwarded message ----------
> Date: Sat, 10 Jan 1998 16:37:50 +0200
> From: Rauli Ruohonen <raulir@fishy.pp.sci.fi>
> Reply-To: raulir@voimax.voima.jkl.fi
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: lack of raw disk devices
>
> Ralf wrote:
>>On Mon, Jan 05, 1998 at 05:11:11PM -0500, jhohertz@golden.net wrote:
>>
>>> Hey.... I may have said this to the list already, but, is it possible
>>> to just
>>> make an ioctl() for the block devices that turns off the buffering?
>>> Seems a
>>> more elegant solution than having a two device files for every single
>>> block
>>> device.
>>
>>That's at least what legacy software expects ...
>>
>>The whole matter is a bit more complicated because some devices (actually
>>a whole lot of intelligent hardware) do massive reordering of pending i/o
>>requests. So a real solution has to include work on device driver level.
>>Somebody is actually working on that but it will take a while.
>
> 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?
>
----------
Sincerely Yours,
Simon Shapiro
Shimon@Simon-Shapiro.ORG Voice: 503.799.2313