/dev/raw support?

[PhiloVivero]

Alan Shutko wrote:

> PhiloVivero <pvspam-dntrepl at hacklab.net> writes:
>
> > There's some chmod you can do on your DVD device to turn off buffering
> > for the device. When you're accessing /dev/dvd you're using the raw
> > device whereas if you somehow mounted /dev/dvd to the filesystem, then
> > used files in that directory, you'd be using 'cooked.'
>
> Could you please check
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.2/0592.html
> and explain please?

Sure. I looked. There's a lot of misinformation out there, and either he's
unaware of the subtleties or it's a lot simpler than I think.

I've looked at other posts
eg: http://www.uwsg.indiana.edu/hypermail/linux/kernel/9703.3/0375.html and it
appears to me that Linux raw devices is an abomination.

Here's a rundown.

Raw I/O: Provide the application some low-level access to the hardware. Yep,
this usually means don't buffer anything but, you know what? It doesn't have
to mean that at all. In fact, the cause of raw device support being so slow to
come is Linus didn't like the idea of letting the userland app usurp control
of buffering. What this means is Linus also doesn't completely get raw I/O.
But then, we're just bickering over syntax, Linus and I. If you can agree on a
definition, you can make progress.

Buffered I/O: Let the OS buffer whatever I/O the app is doing, transparently.
Not necessarily tied to raw I/O (again, Linus may disagree -- I believe raw
devices are unbuffered in Linux? Which is why I claim in some OSen the
capabilities are tied together). Read this:
http://sunsite.dk/linux-newbie/Linux_commands.htm -- here's a quote:

     mknod /dev/fd0 b 2 0
     (=make node, as root) Manually create a device file. This example
     shows how to create a device file associated with your first floppy
     drive and could be useful if you happened to accidentally erase it.
     The options are: b=block mode device, c=character mode device,
     p=FIFO device, u=unbuffered character mode device.

Notice this device fd0 could be UNBUFFERED without dealing with /dev/raw*. I'm
fairly certain there's a chmod switch that'll do this, too.

Asynch/Synch I/O: Unimportant for DVD playback, but of utmost importance for
RDBMS packages.

> As I understand it, access to /dev/hdc or /dev/dvd is still going
> through the buffer cache, though not the page cache.  /dev/raw* was
> devised to stop this, and OMS and xine both claim to support it.

You're probably 100% right, although you could have done unbuffered I/O before
/dev/raw* came to the scenes. I know this because I did it in 2.2 for Sybase.
I recall Wim Ten Have giving the 'chmod' syntax for doing it on the ASE for
Linux mailing list I mentioned in the earlier post.

I have no clue what buffer vs. page cache is.

> It's ok, but I'm still confused.

It took me weeks of talking to Sybase people, Sybase professionals, and kernel
hackers to get it all straightened out, and now that a year has passed, who
knows what has changed. I seriously doubt you must use /dev/raw* to get
unbuffered I/O in 2.4.

More history:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.2/0284.html

Look particularly at the section mentioning "O_SYNC" because this is what the
chmod command I keep alluding to tweaks.

--
PhiloVivero

ps -- in case you haven't noticed, this subject is complicated and there's a
*LOT* of misinformation out there. kernel source would be a good place to look
to be sure how unbuffered I/O can be achieved. I wouldn't trust any posts,
even on the kernel traffic list. Certainly not from some goob (like me) on a
DVD player mailing list.