From: Kay Sievers <kay.sievers@vrfy.org>
To: Tejun Heo <tj@kernel.org>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal
Date: Tue, 14 Sep 2010 10:07:49 +0200 [thread overview]
Message-ID: <AANLkTinGHB9fbLw1Cm5wvPLGy8QEuoBBmFiqpnvXiZ8R@mail.gmail.com> (raw)
In-Reply-To: <4C8F2699.3020509@kernel.org>
On Tue, Sep 14, 2010 at 09:39, Tejun Heo <tj@kernel.org> wrote:
> On 09/14/2010 03:27 AM, Maxim Levitsky wrote:
>>> However 2.6.36 doesn't detect that removal.
>>> According to udevadm monitor --property no uevents are send on removal.
>> Correction, this is regression between 2.6.34 and 2.6.35. This shows how
>> much I use cd these days...
>>
>> I bisected it down to this:
>>
>> 6b4517a7913a09d3259bb1d21c9cb300f12294bd is the first bad commit
>> commit 6b4517a7913a09d3259bb1d21c9cb300f12294bd
>> Author: Tejun Heo <tj@kernel.org>
>> Date: Wed Apr 7 18:53:59 2010 +0900
>>
>> block: implement bd_claiming and claiming block
>
> Hmmm... weird. This commit does change the open behavior but
> shouldn't change the end result. Can someone please enlighten me how
> udevadm is interacting with the device at system call level?
Not at all. Udev does not really touch it.
The cdrom drive isn't unlocked on usual systems, udisks polls the
cdrom drive periodically just like HAL did. The only difference is
that with the polling, the sr driver detects a media change and sends
a uevent to udev, instead of HAL looking at the result of the open().
Are we sure, that there is something that still polls the drive?
Udisks is only auto-started, when the desktop calls into some D-Bus
methods, unlike HAL where it was an init script.
Kay
next prev parent reply other threads:[~2010-09-14 8:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-12 9:49 [REGRESSION] cdrom drive doesn't detect removal Maxim Levitsky
2010-09-14 1:27 ` Maxim Levitsky
2010-09-14 7:39 ` Tejun Heo
2010-09-14 8:07 ` Kay Sievers [this message]
2010-09-14 23:38 ` Maxim Levitsky
2010-09-14 23:49 ` Kay Sievers
2010-09-15 0:37 ` Maxim Levitsky
2010-09-15 1:01 ` Kay Sievers
2010-09-15 13:27 ` Henrique de Moraes Holschuh
2010-09-15 13:44 ` Kay Sievers
2010-09-15 22:20 ` Maxim Levitsky
2010-09-16 6:51 ` Kay Sievers
2010-09-21 11:42 ` Maxim Levitsky
2010-09-21 23:09 ` Maxim Levitsky
2010-09-22 7:38 ` Tejun Heo
2010-09-22 13:41 ` Maxim Levitsky
2010-09-22 13:58 ` Maxim Levitsky
2010-09-23 8:47 ` Tejun Heo
2010-09-23 9:21 ` Kay Sievers
2010-09-30 6:30 ` Florian Mickler
2010-09-30 7:48 ` Kay Sievers
2010-09-30 11:38 ` Florian Mickler
2010-09-30 14:17 ` Maxim Levitsky
2010-09-30 14:49 ` Florian Mickler
2010-09-30 19:27 ` Kay Sievers
2010-09-30 20:14 ` Florian Mickler
2010-09-30 20:32 ` Kay Sievers
2010-09-30 20:47 ` Florian Mickler
2010-09-30 20:57 ` Kay Sievers
2010-10-01 5:55 ` Tejun Heo
2010-10-01 7:54 ` Florian Mickler
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=AANLkTinGHB9fbLw1Cm5wvPLGy8QEuoBBmFiqpnvXiZ8R@mail.gmail.com \
--to=kay.sievers@vrfy.org \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.