From: David Zeuthen <david@fubar.dk>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Matthew Garrett <mjg@redhat.com>,
linux-kernel@vger.kernel.org, axboe@kernel.dk,
linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] [RFC] Add support for uevents on block device idle
Date: Tue, 17 Nov 2009 16:09:40 +0000 [thread overview]
Message-ID: <1258474180.16176.62.camel@localhost.localdomain> (raw)
In-Reply-To: <ac3eb2510911170755i5188fb53ud2d6012a2db8c00a@mail.gmail.com>
On Tue, 2009-11-17 at 16:55 +0100, Kay Sievers wrote:
> I guess, at the moment the disk tells it's idle, udev will open() the
> disk and look for changed signatures, and end its idle state. :)
Huh, this will probably cause interesting loops then ;-)
> Uevents might not be the right interface, they are usually used if the
> device needs to be (re-)examined, which will the idle thing into a
> loop with the current setups, I guess.
Yeah.
> Maybe we can use a sysfs file which can be open()'d and something can
> watch with poll(), and gets woken up by the kernel, after the drive
> changes its state? MD raid, as an example, has files like this in
> sysfs to allow monitoring. That way, there is also no overhead, if the
> requesting process goes away, which is usually the nicer interface,
> than a global switch, which does not care about if the requesting
> process still exists.
Can't we just use /sys/block/sdX/stat? I believe this file already has
the property that the contents of the file will stay constant exactly
when the device is idle. Being able to use poll() for change
notifications seems like a good interface.
Thanks,
David
next prev parent reply other threads:[~2009-11-17 16:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 14:37 [PATCH] [RFC] Add support for uevents on block device idle changes Matthew Garrett
2009-11-17 15:55 ` [PATCH] [RFC] Add support for uevents on block device idle Kay Sievers
2009-11-17 16:09 ` David Zeuthen [this message]
2009-11-17 18:57 ` Matthew Garrett
2009-11-18 19:30 ` Kay Sievers
2009-11-18 19:40 ` Matthew Garrett
2009-11-18 19:47 ` Kay Sievers
2009-11-18 19:53 ` Matthew Garrett
2009-11-18 20:03 ` Kay Sievers
2009-11-18 20:07 ` Matthew Garrett
2009-11-18 21:06 ` Kay Sievers
2009-11-18 21:29 ` Kay Sievers
2009-11-18 21:35 ` Matthew Garrett
2009-11-18 21:39 ` Kay Sievers
2009-11-18 21:45 ` Matthew Garrett
2009-11-18 21:33 ` Matthew Garrett
2009-11-18 21:40 ` Kay Sievers
2009-11-19 11:09 ` Kay Sievers
2009-11-19 13:01 ` Matthew Garrett
2009-11-19 13:29 ` Kay Sievers
2009-11-19 14:16 ` Matthew Garrett
2009-11-19 14:25 ` Kay Sievers
2009-11-19 14:30 ` Matthew Garrett
2009-11-19 14:34 ` Kay Sievers
2009-11-19 14:48 ` Matthew Garrett
2009-11-19 15:00 ` Kay Sievers
2009-11-20 20:29 ` Matthew Garrett
2009-11-22 23:37 ` Pavel Machek
2009-11-23 14:12 ` Matthew Garrett
2009-11-23 14:17 ` Jens Axboe
2009-11-23 14:25 ` Matthew Garrett
2009-11-23 14:31 ` Jens Axboe
2009-11-23 14:42 ` Matthew Garrett
2009-11-23 19:50 ` Jens Axboe
2009-11-23 19:54 ` Matthew Garrett
2009-11-18 22:10 ` [PATCH] [RFC] Add support for uevents on block device idle changes Bartlomiej Zolnierkiewicz
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=1258474180.16176.62.camel@localhost.localdomain \
--to=david@fubar.dk \
--cc=axboe@kernel.dk \
--cc=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.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;
as well as URLs for NNTP newsgroup(s).