On 10-11-01 02:44 PM, Tejun Heo wrote:
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.
Tejun,
Yes. You could add the SCSI FORMAT UNIT and the ATA
(and soon SCSI) SANITIZE commands to that example.
Compliant SCSI units should respond to such an untimely
TEST UNIT READY with the additional sense of "logical
unit not ready, format in progress" but many devices
don't leading to error recovery and device resets.
Ideally I would like to see a way from the user space
to uncouple a unit from the sd (or sr) driver, in a
similar way to how an LLD can use
scsi_device::no_uld_attach . That would restrict user
space access to the bsg or sg driver. Another approach
is to flag the sd (or sr) driver to not send any !@#$%^&
commands to a device until further notice.
Doug Gilbert
* Userland polling is unnecessarily heavy and in-kernel implementation
is lighter and better coordinated (workqueue, timer slack).
<snip>
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
