public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Samphan Raruenrom <samphan@nectec.or.th>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, Linux TLE Team <rdi1@opentle.org>,
	Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: [Rdi1] Re: [PATCH] Add MOUNT_STATUS ioctl to cdrom device
Date: Tue, 26 Aug 2003 13:36:33 +0200	[thread overview]
Message-ID: <20030826113633.GA22124@suse.de> (raw)
In-Reply-To: <3F4B44C2.4030406@nectec.or.th>

On Tue, Aug 26 2003, Samphan Raruenrom wrote:
> >Exactly. You poll media events from the drive, and upon an eject request
> >you try and umount it. If it suceeds, you eject the tray. 
> 
> No, it seems impossible to sense the eject request (right?). This

No it isn't, in fact there are several ways to do it. Just by searching
this list you should be able to find them.

> is what I really did with the patched kernel and patched magicdev.

magicdev is a piece of crap.

> When, for example:-
> 
> - user insert CD
> - magicdev sense the CD, mount /dev/cdrom -> eject is ok
> - user play an mp3 file in the disc
> - magicdev found MOUNT_STATUS=BUSY, lock the drive -> eject disabled
> - user stop using any file on the disc
> - magicdev found MOUNT_STATUS=MOUNTED, unlock the drive -> eject is ok
> - user push the eject button, the disc pop out because it's not locked.
> - magicdev sense empty drive, umount /dev/cdrom

That's not the way to do it. For drives that support media status event
reporting you don't lock the drive, you just intercept the eject
request. And at that time you check if you can umount /cdrom (or
whatever) - if that suceeds, you send an eject request to the drive.
This will work with any drive made in the last few years. You can also
check out MS media status notification, I think you can even find that
document on microsoft.com.

I think you need to spend a little more time thinking/researching this
problem. At least it really looks like you are going about it all wrong.

-- 
Jens Axboe


  reply	other threads:[~2003-08-26 11:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-25 18:22 [PATCH] Add MOUNT_STATUS ioctl to cdrom device Samphan Raruenrom
2003-08-25 18:50 ` Christoph Hellwig
2003-08-26  6:50   ` Samphan Raruenrom
2003-08-26  7:32     ` Christoph Hellwig
2003-08-26  9:09       ` Samphan Raruenrom
2003-08-26  9:56         ` Christoph Hellwig
2003-08-26  9:58           ` Jens Axboe
2003-08-26 11:30             ` [Rdi1] " Samphan Raruenrom
2003-08-26 11:36               ` Jens Axboe [this message]
2003-08-26 12:44                 ` Samphan Raruenrom
2003-08-26 14:16                   ` Jens Axboe
2003-08-26 13:58               ` Christoph Hellwig
2003-08-26 15:32                 ` Samphan Raruenrom
2003-08-26 15:45                   ` Jens Axboe
2003-08-25 20:03 ` viro

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=20030826113633.GA22124@suse.de \
    --to=axboe@suse.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=rdi1@opentle.org \
    --cc=samphan@nectec.or.th \
    /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