Re: [PATCH] RFC scsi_error: handle REPORT_LUNS_DATA_CHANGED, CAPACITY_DATA_CHANGED,

[Mike Christie <michaelc@cs.wisc.edu>]

FUJITA Tomonori wrote:
> On Mon, 20 Apr 2009 11:55:52 +0200
> Hannes Reinecke <hare@suse.de> wrote:
> 
>> 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.
> 
> Do we really have huge amount of messages, errors, unit attentions,
> etc?
> 
> We already have a mechanism to send events to user space,
> sdev_evt_send(). Could we simply use (or extend) it?

Yeah, I think we could add a SCSI_EVT_SCSI_SENSE event, then pass the 
sense code and asc and ascq in the envp.