From: Hannes Reinecke <hare@suse.de>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] RFC scsi_error: handle REPORT_LUNS_DATA_CHANGED, CAPACITY_DATA_CHANGED,
Date: Mon, 20 Apr 2009 11:55:52 +0200 [thread overview]
Message-ID: <49EC46A8.1070704@suse.de> (raw)
In-Reply-To: <49E90243.7080806@cs.wisc.edu>
Hi Mike,
Mike Christie wrote:
> Hey Hannes
>
> While we are talking about LSF stuff and you are not busy with distro
> stuff....
>
Ah, irony detector kicked in.
(Current bugilla count is at 114. Ask me about being busy.)
> I implemented this based on what we talked about at the last LSF.
>
Yes, I've seen it. You again beat me to it; I've done an initial implementation
already but failed to send it mainline. Sigh.
But yes, we _do_ need something like this.
> I was thinking that maybe using kobject_uevent_env would be better. The
> info that gets passed to userspace would be the decoded sense and
> asc/ascq based on values from the drivers/scsi/constants.c.
>
No. This patch has the possibility of generating _huge_ amounts of
messages, most of which are information only and of no influence
to the actual operation.
udev would be flooded with it and won't be able to react to 'important'
messages while processing them.
Hence a separate mechanism like the proposed SCSI generic netlink
facility is the better approach.
> I was also thinking that a udev rule could then just handle something
> like rescanning for REPORT_LUNS_DATA_CHANGED and handle
> CAPACITY_DATA_CHANGED by doing all the crap that has to be done.
>
Yes, that was my initial thought, too. But Kay objected because
of the possible message flooding in udev so we have to use a
separate facility here.
Actually, I already have a daemon implemented. I can drop you
a pointer to the location if required.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-04-20 9:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-31 18:47 [PATCH] RFC scsi_error: handle REPORT_LUNS_DATA_CHANGED, CAPACITY_DATA_CHANGED, michaelc
2009-04-17 22:27 ` Mike Christie
2009-04-20 9:55 ` Hannes Reinecke [this message]
2009-04-20 19:35 ` Mike Christie
2009-05-08 0:41 ` FUJITA Tomonori
2009-05-08 3:06 ` Mike Christie
2009-05-20 14:46 ` Hannes Reinecke
2009-05-21 15:23 ` Mike Christie
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=49EC46A8.1070704@suse.de \
--to=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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).