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

[Hannes Reinecke <hare@suse.de>]

Hi James,

James Smart wrote:
> 
> 
> Hannes Reinecke wrote:
>>> This patch was cut against scsi-misc-2.6, and depends on Mike 
>>> Christies patches contained in the original thread.
>>>
>> Hmph.
>>
>> I don't quite agree with this one.
>> For once, /proc/scsi/scsi has been marked as 'obsolete' for quite some 
>> time now,
>> so adding other usages to this is of questionable value.
> 
> Um... I didn't think I added a new use for it.  The existing data had to
> be extended by an additional argument.
> 
Well, extending the existing structure comes quite close to adding another
usage ...

>>
>> And we've actually have a similar issue when developing the SCSI 
>> device_handler stuff where we also have a device list to maintain.
>>
>> Seeing there is quite some overlap between those two cases I think we 
>> should come up with a way of handling these things properly, ie tied
>> into sysfs.
> 
> Ok - but I see it as a two part process. I am not signing up for replacing
> the device list infrastructure.  But, now that there is target queue depth
> management in the midlayer, I believe we should be taking advantage of it.
> I'd rather see the additional field go in, then see a separate effort to
> replace/collapse the device lists...
> 
Ok, agreed. It makes sense to have it now and update the infrastructure
later.

>> So, what we should do here is
>> a) add a 'can_queue' sysfs attribute to the starget (which we can 
>> nowadays, as the starget is a proper sysfs object)
> 
> Um, it exists under the /sys/devices tree (the base object) but there is no
> class representation. Are you requesting this goes on the base object ?
> I thought we avoided this.
Yes. Although I can't figure out _why_.
We nowadays have perfectly valid scsi_target kobj, which can (and will if
CONFIG_SYSFS_DEPRECATED is not set) be displayed in sysfs.

> I guess it can, but as it's scsi-ish, I would
> think it more appropriate to formally create a scsi_target class and put
> scsi attributes there.  (but I was avoiding that too)
> 
We don't have to. It's just the once upon a time a class object was
used to access the underlying object. But nowadays the destinction
between class_objects and 'normal' objects is gone so there's hardly
any point in creating one.

I personally don't have a problem with putting the 'generic' SCSI
sysfs attributes into the kobj itself and getting rid of the class
devices for it (or rather, make it a link).
And, actually, plan to do some patches for it :-)

But that's slightly off-topic here.
And as we don't have a consensus about the future sysfs layout
yet it hardly makes any sense to discuss the placement of target
specific attributes.

So:
Acked-by: Hannes Reinecke <hare@suse.de>

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