[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1291838262-21274-1-git-send-email-tj@kernel.org>
Date: Wed, 8 Dec 2010 20:57:34 +0100
From: Tejun Heo <tj@...nel.org>
To: jeff@...zik.org, linux-ide@...r.kernel.org, axboe@...nel.dk,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
kay.sievers@...y.org, jack@...e.cz,
James.Bottomley@...senPartnership.com
Subject: [PATCHSET] block/SCSI: implement in-kernel disk event handling, take#2
This is the second take of in-kernel-disk-event patchset which
implements in-kernel disk event handling framework and adds 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.
Changes from the last take[L] are,
- Rebased on top of the current block#for-2.6.38/core branch.
- TUR error handling in sr was incorrect both before and after the
patchset. 0005-scsi-fix-TUR-error-handling-in-sr_media_change.patch
is added to fix the bug.
- For both sr and sd, ->media_present should be initialized to 1
instead of 0. This fixes problems with initial partition scan
spotted by Kay.
- Various misc updates - comments, patch descriptions, etc.
>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 eight 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-fix-TUR-error-handling-in-sr_media_change.patch
0006-scsi-replace-sr_test_unit_ready-with-scsi_test_unit_.patch
0007-sr-implement-sr_check_events.patch
0008-sd-implement-sd_check_events.patch
0001-0002 are prepreations. 0003 implements the block layer framework
for disk event handling. 0004-0008 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!).
This patchset is on top of block#for-2.6.38/core 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 | 95 ++++----
drivers/scsi/sd.h | 1
drivers/scsi/sr.c | 172 ++++++++-------
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, 778 insertions(+), 269 deletions(-)
Thanks.
--
tejun
[L] http://thread.gmane.org/gmane.linux.scsi/63258
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists