making the queue_type attribute read only, was: Re: tag handling refactor V2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>  - how is the change_queue_type API supposed to be used for most drivers?  It
>    only changes the tag type from none to simple or back, but except for the
>    special implementation in the 53c700 driver doesn't change the queue depth,
>    which might cause it to issue multiple non-tagged command.  Fortunately
>    most drivers never look at this information, but then again changing the
>    queue type is useless to start with.
>  - for those drivers looking at the command tagged information we'd need
>    to quiesce the LUN.  No driver but the 53c700 driver does that, and the
>    53c700 does it at a target-level, which despite a comment claiming it's
>    needed doesn't seem to make sense given the code.  If we can make sure
>    to quience all LUNs we could avoid the per-command flag for tagged commands
>    and always look at the scsi_device flag.

I've not merged the series, but ondering the above two issues I've
become convinved that we should make the queue_type sysfs attribute read
only.

Switching off tagging isn't really something we should leave to users,
as the hardware knows much better.  Changing the tag type might have
made sense during the times of the ordered tags for barriers insanity,
but now that it's just tagged vs untagged it's pretty pointless.
Especially given that only a single driver ever got the implementation
right.

Does anyone have objections to removing the change_queue_type method?

--
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux