Re: Problems with eject and pktcdvd

[Phillip Susi]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/