On Sat, 2017-07-08 at 02:52 -0500, Mike Christie wrote:
> Userspace tools like targetcli are not able to dynamically detect if a
> tcmu device supports kernel features ALUA or PGRs. In some kernels it
> can create ALUA groups, but writing/reading ALUA files can lead to
> nice error codes but also crashes and hangs.
>
> This patch, made over Nicks's for next branch, adds a device configfs
> attribute to report the kernel features the device supports, so tools
> can check that before attempting to activate some of these features
> that were partially supported in older kernels.
>
> It can also be used for future feautes like possibly inquiry suppport
> if we do end up moving that to the kernel so we can properly report
> port info.
>
> [ ... ]
> +static ssize_t tcmu_features_show(struct config_item *item, char *page)
> +{
> + struct se_dev_attrib *da = container_of(to_config_group(item),
> + struct se_dev_attrib, da_group);
> + struct tcmu_dev *udev = TCMU_DEV(da->da_dev);
> +
> + return snprintf(page, PAGE_SIZE, "0x%llx\n", udev->features);
> +}
> +CONFIGFS_ATTR_RO(tcmu_, features);
>
> [ ... ]
>
> diff --git a/include/uapi/linux/target_core_user.h b/include/uapi/linux/target_core_user.h
> index 24a1c4e..03de6e9 100644
> --- a/include/uapi/linux/target_core_user.h
> +++ b/include/uapi/linux/target_core_user.h
> @@ -154,4 +154,7 @@ enum tcmu_genl_attr {
> };
> #define TCMU_ATTR_MAX (__TCMU_ATTR_MAX - 1)
>
> +#define TCMU_KERN_ALUA (1ULL << 0)
> +#define TCMU_KERN_PGR (1ULL << 1)
Hello Mike,
Wouldn't it be more convenient for shell scripts if the state of these flags
would be exported through two configfs attributes instead of a single bitfield?
Wouldn't that be more consistent with other sysfs/configfs drivers that export
boolean values?
Thanks,
Bart.��.n��������+%������w��{.n����j� ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
