linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: Tejun Heo <tj@kernel.org>
Cc: 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: Re: [PATCHSET RFC] block/SCSI: implement in-kernel disk event handling
Date: Thu, 04 Nov 2010 13:07:06 -0400	[thread overview]
Message-ID: <4CD2E83A.9020309@interlog.com> (raw)
In-Reply-To: <1288637081-5183-1-git-send-email-tj@kernel.org>

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


  parent reply	other threads:[~2010-11-04 17:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-01 18:44 [PATCHSET RFC] block/SCSI: implement in-kernel disk event handling Tejun Heo
2010-11-01 18:44 ` [PATCH 1/7] block: kill genhd_media_change_notify() Tejun Heo
2010-11-01 18:44 ` [PATCH 2/7] block: move register_disk() and del_gendisk() to block/genhd.c Tejun Heo
2010-11-01 18:44 ` [PATCH 3/7] implement in-kernel gendisk events handling Tejun Heo
2010-11-01 18:44 ` [PATCH 4/7] cdrom: add ->check_events() support Tejun Heo
2010-11-01 18:44 ` [PATCH 5/7] scsi: replace sr_test_unit_ready() with scsi_test_unit_ready() Tejun Heo
2010-11-01 18:44 ` [PATCH 6/7] sr: implement sr_check_events() Tejun Heo
2010-11-01 18:44 ` [PATCH 7/7] sd: implement sd_check_events() Tejun Heo
2010-11-04 17:07 ` Douglas Gilbert [this message]
2010-11-04 18:37   ` [PATCHSET RFC] block/SCSI: implement in-kernel disk event handling Mike Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD2E83A.9020309@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@kernel.dk \
    --cc=jack@suse.cz \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).