On 10/15/2014 10:48 PM, Rufe Glick wrote:
Hello all, Just a feedback of a newcomer to the targetcli. Some boolean parameters accept true or false, e.g. 'set global auto_cd_after_create=true|false'; while other boolean parameters accept 0 or 1, e.g. 'set attribute authentication=1|0'.
And there is even Yes|No for RFC-3720 parameters like DataPDUInOrder or DataSequenceInOrder !!!
The parameters/attributes difference is due to the kernel-side and the fact that in 2.x series, we simply pass the values through as there is no way to check the type in a generic manner (see previous posts in this thread). The targetcli UI attributes format is a decision I made years ago, perhaps for bad reasons (I hoped to get rid of 0|1 and Yes|No sooner and unify on a better syntax).
With 3.x and its future configuration shell (for now in early preview), which will eventually replace the current shell for config, this is unified as 3.x uses policy files defining unified trypes that get translated correctly on the kernel side.
It doesn't bother me much, but it would be nice to eliminate these inconsistencies. That'll make overall user experience a bit more smooth and consistent.
Agreed.
The other thing of the same nature is paramter naming. Some of them come with underscores, e.g. 'set global auto_cd_after_create' and friends; while others come in camel case, e.g. 'set parameter AuthMethod'.
Again, this is the kernel-side naming of things. AFAIK, only RFC-3720 parameters use camel case. On this front, I have no solution yet, and am not too sure it is overall desirable (naming consistency vs consistency with the kernel side, 3rd party scripts and legacy rtslib scripts). I'll keep that in mind though.
-- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
