From: Jens Axboe <axboe@kernel.dk>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, kay.sievers@vrfy.org,
linux-hotplug@vger.kernel.org
Subject: Re: [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from
Date: Fri, 01 Jul 2011 14:18:59 +0000 [thread overview]
Message-ID: <4E0DD753.1090202@kernel.dk> (raw)
In-Reply-To: <20110630154822.GR3386@htj.dyndns.org>
On 2011-06-30 17:48, Tejun Heo wrote:
> Currently, only open(2) is defined as the 'clearing' point. It has
> two roles - first, it's an acknowledgement from userland indicating
> that the event has been received and kernel can clear pending states
> and proceed to generate more events. Secondly, it's passed on to
> device drivers as a hint indicating that a synchronization point has
> been reached and it might want to take a deeper look at the device.
>
> The latter currently is only used by sr which uses two different
> mechanisms - GET_EVENT_MEDIA_STATUS_NOTIFICATION and TEST_UNIT_READY
> to discover events, where the former is lighter weight and safe to be
> used repeatedly but may not provide full coverage. Among other
> things, GET_EVENT can't detect media removal while TUR can.
>
> This patch makes close(2) - blkdev_put() - indicate clearing hint for
> MEDIA_CHANGE to drivers. disk_check_events() is renamed to
> disk_flush_events() and updated to take @mask for events to flush
> which is or'd to ev->clearing and will be passed to the driver on the
> next ->check_events() invocation.
>
> This change makes sr generate MEDIA_CHANGE when media is ejected from
> userland - e.g. with eject(1).
>
> Note: Given the current usage, it seems @clearing hint is needlessly
> complex. disk_clear_events() can simply clear all events and the hint
> can be boolean @flush.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Kay Sievers <kay.sievers@vrfy.org>
> ---
> Jens, this patch is for 3.1 merge window but generated on top of the
> current block:for-linus because it depends on the fixes in that
> branch. It would probably be best to pull in for-linus into
> for-2.6.32/core before applying this patch.
Apart from some branch confusing in your email, I did that :-)
Applied, thanks.
--
Jens Axboe
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, kay.sievers@vrfy.org,
linux-hotplug@vger.kernel.org
Subject: Re: [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from drivers on close(2)
Date: Fri, 01 Jul 2011 16:18:59 +0200 [thread overview]
Message-ID: <4E0DD753.1090202@kernel.dk> (raw)
In-Reply-To: <20110630154822.GR3386@htj.dyndns.org>
On 2011-06-30 17:48, Tejun Heo wrote:
> Currently, only open(2) is defined as the 'clearing' point. It has
> two roles - first, it's an acknowledgement from userland indicating
> that the event has been received and kernel can clear pending states
> and proceed to generate more events. Secondly, it's passed on to
> device drivers as a hint indicating that a synchronization point has
> been reached and it might want to take a deeper look at the device.
>
> The latter currently is only used by sr which uses two different
> mechanisms - GET_EVENT_MEDIA_STATUS_NOTIFICATION and TEST_UNIT_READY
> to discover events, where the former is lighter weight and safe to be
> used repeatedly but may not provide full coverage. Among other
> things, GET_EVENT can't detect media removal while TUR can.
>
> This patch makes close(2) - blkdev_put() - indicate clearing hint for
> MEDIA_CHANGE to drivers. disk_check_events() is renamed to
> disk_flush_events() and updated to take @mask for events to flush
> which is or'd to ev->clearing and will be passed to the driver on the
> next ->check_events() invocation.
>
> This change makes sr generate MEDIA_CHANGE when media is ejected from
> userland - e.g. with eject(1).
>
> Note: Given the current usage, it seems @clearing hint is needlessly
> complex. disk_clear_events() can simply clear all events and the hint
> can be boolean @flush.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Kay Sievers <kay.sievers@vrfy.org>
> ---
> Jens, this patch is for 3.1 merge window but generated on top of the
> current block:for-linus because it depends on the fixes in that
> branch. It would probably be best to pull in for-linus into
> for-2.6.32/core before applying this patch.
Apart from some branch confusing in your email, I did that :-)
Applied, thanks.
--
Jens Axboe
next prev parent reply other threads:[~2011-07-01 14:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 15:48 [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from drivers Tejun Heo
2011-06-30 15:48 ` [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from drivers on close(2) Tejun Heo
2011-07-01 14:18 ` Jens Axboe [this message]
2011-07-01 14:18 ` Jens Axboe
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=4E0DD753.1090202@kernel.dk \
--to=axboe@kernel.dk \
--cc=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.