On 10/15/2014 10:28 PM, Rufe Glick wrote:
On Wed, Oct 15, 2014 at 4:06 AM, Jerome Martin <jxm@xxxxxxxxxxx> wrote:
On 10/15/2014 03:02 AM, Andy Grover wrote:
On 10/13/2014 08:37 PM, Rufe Glick wrote:
[...]
So when generate_node_acls is set to 0, the cache_dynamic_acls setting
has no effect by definition. When generate_node_acls is set to 1, the
cache_dynamic_acls is set to 1 by the kernel anyway. So maybe you
shouldn't expose that configuration parameter in the targetcli
altogether? Or do you keep it there for compatibility reasons? Then
you could at least mark it as obsolete in the man page and in the
short description available in the targetcli by typing 'get attribute'
+ Enter in the TPG context.
First, I want to point out that before hiding this attribute, I want to
double check with Nic and co that there is not a use-case that I have
missed for the iSCSI demo-mode that would require to manually tweak the
cache_dynamic_acls.
That being said - c.f. my previous reply on that thread - a specific
version of targetcli should not be tied to a specific version of the
kernel modules. So some degree of backward-compatibility and legacy
support is maintained. There are many examples of this if you look at
some differences between Andy's version and upstream targetcli, notably
legacy backstore mode, ramdisk support, etc.
Of course, there has to be a limit to this, and I do not have a fixed
policy about it, and have tended to err in the past on the side of more
legacy support than maybe was absolutely required. Part of the reason is
that the ecosystem using these tools range from behemoth SAN systems to
tiny embedded non-x86 systems with tiny environments, some of which
using very old kernels with cherry-picked backports.
Now, for attributes and parameters, these have historically been picked
up on-the-fly by rtslib in the configfs node created for a new target
object, as a way to ensure genericity. Now, with 3.x, we have an
additional abstraction layer that allows us to tweak what we expose and
how we expose it a bit more, while preserving genericity.
I just added cache_dynamic_acls to my TODO for verification, and if Nic
confirms that there are no "normal" usecase for it, will implement your
suggestion in one form or an other, probably simply hiding the attribute
while allowing manual input for it for legacy support.
Many thanks for your suggestions, I am in need of that kind of usability
feedback.
Regards,
--
Jerome
--
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
