Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755702Ab0KASqY (ORCPT ); Mon, 1 Nov 2010 14:46:24 -0400 Received: from hera.kernel.org ([140.211.167.34]:37385 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755512Ab0KASpA (ORCPT ); Mon, 1 Nov 2010 14:45:00 -0400 From: Tejun Heo To: axboe@kernel.dk, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, kay.sievers@vrfy.org, jack@suse.cz, James.Bottomley@HansenPartnership.com Subject: [PATCHSET RFC] block/SCSI: implement in-kernel disk event handling Date: Mon, 1 Nov 2010 19:44:34 +0100 Message-Id: <1288637081-5183-1-git-send-email-tj@kernel.org> X-Mailer: git-send-email 1.7.1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (hera.kernel.org [127.0.0.1]); Mon, 01 Nov 2010 18:44:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3565 Lines: 87 This patchset implements in-kernel disk event handling framework and add support for it to sr and sd. This is largely to move media presence polling into kernel as userspace implementation turned out to be quite problematic over the years. >From the patch description of the third patch, Currently, media presence polling for removeable block devices is done from userland. There are several issues with this. * Polling is done by periodically opening the device. For SCSI devices, the command sequence generated by such action involves a few different commands including TEST_UNIT_READY. This behavior, while perfectly legal, is different from Windows which only issues single command, GET_EVENT_STATUS_NOTIFICATION. Unfortunately, some ATAPI devices lock up after being periodically queried such command sequences. * There is no reliable and unintrusive way for a userland program to tell whether the target device is safe for media presence polling. For example, polling for media presence during an on-going burning session can make it fail. The polling program can avoid this by opening the device with O_EXCL but then it risks making a valid exclusive user of the device fail w/ -EBUSY. * Userland polling is unnecessarily heavy and in-kernel implementation is lighter and better coordinated (workqueue, timer slack). This patchset contains the following seven patches. 0001-block-kill-genhd_media_change_notify.patch 0002-block-move-register_disk-and-del_gendisk-to-block-ge.patch 0003-implement-in-kernel-gendisk-events-handling.patch 0004-cdrom-add-check_events-support.patch 0005-scsi-replace-sr_test_unit_ready-with-scsi_test_unit_.patch 0006-sr-implement-sr_check_events.patch 0007-sd-implement-sd_check_events.patch 0001-0002 are prepreations. 0003 implements the block layer framework for disk event handling. 0004-0007 add support for it to cdrom and then sr and sd. Block drivers just need to implement a new bdev method ->check_events() which supercedes ->media_change() and set bdev->events[_async] masks according to what the device can do. Everything else is handled by block layer including event generation, polling and its configuration. Tested with dvd drives and an iomega click drive (a removable direct access ATAPI device Alan gave to me, still operational!). Kay, as you're the media presence polling expert :-) how does this look to you? This patchset is on top of v2.6.37-rc1 + clean-up-bdev-claim-release patchset and available in the following git tree, git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git disk-events and contains the following changes. block/genhd.c | 544 +++++++++++++++++++++++++++++++++++++++++++++--- drivers/cdrom/cdrom.c | 55 ++++ drivers/scsi/scsi_lib.c | 13 - drivers/scsi/sd.c | 97 ++++---- drivers/scsi/sd.h | 1 drivers/scsi/sr.c | 168 ++++++++------ drivers/scsi/sr.h | 3 drivers/scsi/sr_ioctl.c | 2 fs/block_dev.c | 41 +++ fs/partitions/check.c | 89 ------- include/linux/blkdev.h | 4 include/linux/cdrom.h | 6 include/linux/fs.h | 1 include/linux/genhd.h | 20 + include/scsi/scsi.h | 1 15 files changed, 774 insertions(+), 271 deletions(-) Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/