public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.
>
>  
>


  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