Re: [PATCH] scsi : set target can_queue from devinfo flags

[Hannes Reinecke <hare@novell.com>]

Hi Mike,

Mike Christie wrote:
> James Smart wrote:
>> This sounds reasonable, but I wouldn't eliminate this can_queue limit. 
> 
> I was not going to elimitate it. It is all muddled in the one mail, so 
> it is confusing.
> 
> I was just going to set it based on target vendor info table in 
> userspace from a scsi daemon that was going to handle this issue and 
> handle ramp ups due to QUEUE_FULL ramp downs and other scsi issues like 
> the handling of sense that indicates disks changes size or report lun 
> data changes.
> 
> Hannes had mentioned he was making some event infrastructure to handle 
> the sense, and I thought I could extend his userspce code to handle the 
> ramp up issue and handle setting this value. So for just the 
> starget->can_queue issue, the daemon would listen for target hotplug 
> events, then it would do sg io to device on it and get the vendor info 
> and look up the target in a table and then if found would write to a 
> starget->can_queue sysfs file to set the value.
> 
Currently I've implemented another scsi netlink event, which just
transports the sense code to the outside world. Next step will be
a daemon which listens to the SCSI netlink events and reacts upon
that; will work largely along the lines udev does.
So we'll be getting a sysfs patch for the device, the message class,
and some payload for the message.
Configuration will quite simple, probably just something like:

[message class]
	[payload regex]	[command]
	[payload regex] [command]

etc.
I'll probably implementing some pre-defined commands like rescan,
but will also add a simple callout for executing commands directly.

> The same daemon could also handle the sense handling and handle other 
> errors like when to ramp up from when we ramp down due to QUEUE_FULLs. 
> So it is basically a scsi-ml/lib in userpsace that could be easily 
> packaged for distros to carry.
Quite easily. Actually, that was the point of that program.

Cheers,

Hannes