Re: [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE fromdrivers on close(2)

From: Jens Axboe
Date: Fri Jul 01 2011 - 10:19:10 EST


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@xxxxxxxxxx>
> Cc: Kay Sievers <kay.sievers@xxxxxxxx>
> ---
> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/