From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Date: Fri, 01 Jul 2011 14:18:59 +0000 Subject: Re: [PATCH block:for-2.6.31/core] block: flush MEDIA_CHANGE from Message-Id: <4E0DD753.1090202@kernel.dk> List-Id: References: <20110630154822.GR3386@htj.dyndns.org> In-Reply-To: <20110630154822.GR3386@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: linux-kernel@vger.kernel.org, kay.sievers@vrfy.org, linux-hotplug@vger.kernel.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 > Cc: Kay Sievers > --- > 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