From: Ewan Milne <emilne@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: Add "missing" sysfs attribute to scsi_device structure
Date: Mon, 18 Nov 2013 12:59:18 -0500 [thread overview]
Message-ID: <1384797558.3839.19.camel@localhost.localdomain> (raw)
In-Reply-To: <1384796756.5985.3.camel@dabdike.int.hansenpartnership.com>
On Mon, 2013-11-18 at 09:45 -0800, James Bottomley wrote:
> On Mon, 2013-11-18 at 12:10 -0500, Ewan D. Milne wrote:
> > From: "Ewan D. Milne" <emilne@redhat.com>
> >
> > This change adds a "missing" sysfs attribute to scsi_device
> > which is set when a previously scanned device no longer appears
> > in the REPORT LUNS inventory.
>
> A sysfs parameter with time and external input dependent semantics
> really doesn't look like a good idea. What is it you're trying to
> achieve that you can't achieve from userspace by watching for the
> events?
>
> James
>
>
Ideally, one would like to remove SCSI LUNs that are no longer being
presented by the device. The information about which LUNs are no
longer there could, I suppose, be obtained from userspace by sending
a REPORT LUNS command, but that is somewhat redundant because the
kernel will issue one anyway when it is instructed to scan the target
for new LUNs. This patch just makes the information visible.
Yes, the information is only valid at a point in time, but that is
true of REPORT LUNS any time it is used. If the LUN inventory changes
again, there will be a new event generated that can be processed.
A udev event handler tell the kernel to scan for new LUNs, and then
potentially tell the kernel to delete scsi_devices that are now missing.
-Ewan
next prev parent reply other threads:[~2013-11-18 17:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 17:10 [PATCH] scsi: Add "missing" sysfs attribute to scsi_device structure Ewan D. Milne
2013-11-18 17:45 ` James Bottomley
2013-11-18 17:59 ` Ewan Milne [this message]
2013-11-18 18:15 ` James Bottomley
2013-11-18 18:28 ` Ewan Milne
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=1384797558.3839.19.camel@localhost.localdomain \
--to=emilne@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.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