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@xxxxxxx +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
