Hannes Reinecke 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.
Ah yeah.
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.
Yeah, please send it. I will hook it up to the other patch using the
scsi generic netlink code.
--
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
