From: Phillip Susi <psusi@cfl.rr.com>
To: Peter Osterlund <petero2@telia.com>
Cc: Damian Pietras <daper@daper.net>, linux-kernel@vger.kernel.org
Subject: Re: Problems with eject and pktcdvd
Date: Sun, 15 Jan 2006 17:23:15 -0500 [thread overview]
Message-ID: <43CACB53.40205@cfl.rr.com> (raw)
In-Reply-To: <m3ek39z09f.fsf@telia.com>
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.
>
>
>
next prev parent reply other threads:[~2006-01-15 22:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-15 12:35 Problems with eject and pktcdvd Damian Pietras
2006-01-15 17:53 ` Phillip Susi
2006-01-15 18:50 ` Damian Pietras
2006-01-15 19:17 ` Phillip Susi
2006-01-15 20:47 ` Peter Osterlund
2006-01-15 21:04 ` Damian Pietras
2006-01-15 21:18 ` Jan Engelhardt
2006-01-15 21:34 ` Peter Osterlund
2006-02-05 19:13 ` Peter Osterlund
2006-02-05 21:07 ` Damian Pietras
2006-02-05 22:44 ` Peter Osterlund
2006-02-06 20:15 ` Damian Pietras
2006-02-11 11:21 ` Peter Osterlund
2006-02-12 10:34 ` Damian Pietras
2006-01-15 22:23 ` Phillip Susi [this message]
2006-01-15 22:55 ` Nix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43CACB53.40205@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=daper@daper.net \
--cc=linux-kernel@vger.kernel.org \
--cc=petero2@telia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox