So mounting opens it in blocking mode, causing it to lock, but pktcdvd
does not open it in blocking mode, so it doesn't get locked until the
mount? Why does the cdrom driver differentiate between the two?
Shouldn't it simply be locked when in use, no matter how it is used?
And shouldn't pktcdvd explicitly unlock the drive when the pktcdvd
device isn't open? For that matter, why is mount opening the cdrom in
blocking mode? Shouldn't the filesystem be sending down async bios?
Peter Osterlund wrote:
If you do
pktsetup 0 /dev/hdc
mount /dev/hdc /mnt/tmp
umount /mnt/tmp
the door will be left in a locked state. (It gets unlocked when you
run "pktsetup -d 0" though.) However, if you do:
pktsetup 0 /dev/hdc
mount /dev/pktcdvd/0 /mnt/tmp
umount /mnt/tmp
the door will be properly unlocked.
The problem is that the cdrom driver locks the door the first time the
device is opened in blocking mode, but doesn't unlock it again until
the open count goes down to zero. The pktcdvd driver tries to work
around that, but it can't do it in the first example because the
mount/umount commands do not involve the pktcdvd driver at all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
