lkml.org 
[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: K3b and 2.6.9?


On Tue, 31 Aug 2004, Tim Fairchild wrote:
>
> On starting k3b seems to use 'safe for reading' commands and 'safe for
> writing' command 0x55 (mode_select?) to test the drive function.

Yes. MODE_SELECT is write-only, because that command can do some bad
things.

> file->f_mode is returning with 0x0d during 'safe for writing' command.

Yes, that's FMODE_READ | FMODE_LSEEK | FMODE_PREAD (ie the device not only
accepts reading, it can do seeks and "pread()" too). Which is what a block
device that was opened with O_RDONLY would have.

> I believe FMODE_WRITE is 0x02 tho don't know where that is defined...

Correct. It's a kernel-internal "readability" thing, defined in
<linux/fs.h> - it's invisible to user space (user space uses the O_RDONLY,
O_WRONLY and O_RDWR defines, which are in a different numbering space)

> If this bit not set does it mean the device is opened for reading?

Yes, it means that the user used O_RDONLY to open the device.

> during a burn?

I agree, it doesn't make much sense, does it? But the fact is, it used to
work, and as a result programs can do it that way because they were tested
that wat.

Linus' law: programs don't do things because they make sense. Programs do
things that happened to work for the programmer.

But exactly _because_ it makes so much sense to just change K3b to use
O_RDWR in its open, I'm hoping that the K3b developers won't complain too
much about the kernel changing to require more strict checking (obviously,
I can understand that _users_ will complain - they only see the "it
stopped working" part).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.205 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site