linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Hannes Reinecke <hare@suse.de>,
	Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: "kbusch@kernel.org" <kbusch@kernel.org>,
	"hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH V2 2/2] nvme-core: use macro defination to define dev attr
Date: Mon, 5 Jun 2023 08:01:52 +0000	[thread overview]
Message-ID: <84e8a7be-51e1-e743-97cd-71eea2d40da6@nvidia.com> (raw)
In-Reply-To: <5dcb4c76-0d97-78d6-d383-7f92e7eb4467@suse.de>

On 6/5/23 00:55, Hannes Reinecke wrote:
> On 6/5/23 08:51, Chaitanya Kulkarni wrote:
>> Insated of duplicating the code for dhchap_secret & dhchap_ctrl_secret,
>> define a macro to register device attribute to create device attribute
>> that will also define store and show helpers.
>>
>> Note that this is not newly invented but followed the same format
>> preasent in block layer and nvme source code.
>> nvme_show_str_function/nvme_show_int_function/
>> nvme_subsys_show_str_function/ nullb_device_##NAME##_show/
>> nullb_device_##NAME##_store/LOOP_ATTR_RO
>>
>> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
>> ---
>>   drivers/nvme/host/sysfs.c | 67 +++++++++++++++------------------------
>>   1 file changed, 25 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
>> index 98becb7a7453..ff72bcfb0ff8 100644
>> --- a/drivers/nvme/host/sysfs.c
>> +++ b/drivers/nvme/host/sysfs.c
>> @@ -407,17 +407,6 @@ static ssize_t dctype_show(struct device *dev,
>>   static DEVICE_ATTR_RO(dctype);
>>     #ifdef CONFIG_NVME_AUTH
>> -static ssize_t nvme_ctrl_dhchap_secret_show(struct device *dev,
>> -        struct device_attribute *attr, char *buf)
>> -{
>> -    struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
>> -    struct nvmf_ctrl_options *opts = ctrl->opts;
>> -
>> -    if (!opts->dhchap_secret)
>> -        return sysfs_emit(buf, "none\n");
>> -    return sysfs_emit(buf, "%s\n", opts->dhchap_secret);
>> -}
>> -
>>   static ssize_t nvme_dhchap_secret_store_common(struct nvme_ctrl *ctrl,
>>           const char *buf, size_t count, bool ctrl_secret)
>>   {
>> @@ -472,38 +461,32 @@ static ssize_t 
>> nvme_dhchap_secret_store_common(struct nvme_ctrl *ctrl,
>>       return count;
>>   }
>>   -static ssize_t nvme_ctrl_dhchap_secret_store(struct device *dev,
>> -        struct device_attribute *attr, const char *buf, size_t count)
>> -{
>> -    struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
>> -
>> -    return nvme_dhchap_secret_store_common(ctrl, buf, count, false);
>> -}
>> -
>> -static DEVICE_ATTR(dhchap_secret, S_IRUGO | S_IWUSR,
>> -    nvme_ctrl_dhchap_secret_show, nvme_ctrl_dhchap_secret_store);
>> -
>> -static ssize_t nvme_ctrl_dhchap_ctrl_secret_show(struct device *dev,
>> -        struct device_attribute *attr, char *buf)
>> -{
>> -    struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
>> -    struct nvmf_ctrl_options *opts = ctrl->opts;
>> -
>> -    if (!opts->dhchap_ctrl_secret)
>> -        return sysfs_emit(buf, "none\n");
>> -    return sysfs_emit(buf, "%s\n", opts->dhchap_ctrl_secret);
>> -}
>> -
>> -static ssize_t nvme_ctrl_dhchap_ctrl_secret_store(struct device *dev,
>> -        struct device_attribute *attr, const char *buf, size_t count)
>> -{
>> -    struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
>> -
>> -    return nvme_dhchap_secret_store_common(ctrl, buf, count, false);
>> -}
>> +#define NVME_AUTH_DEVICE_ATTR(NAME, cs)                    \
>> +static ssize_t nvme_ctrl_##NAME##_show(struct device *dev,        \
>> +        struct device_attribute *attr, char *buf)        \
>> +{                                    \
>> +    struct nvme_ctrl *ctrl = dev_get_drvdata(dev);            \
>> +    struct nvmf_ctrl_options *opts = ctrl->opts; \
>> +                                    \
>> +    if (!opts->NAME)                        \
>> +        return sysfs_emit(buf, "none\n");            \
>> +    return sysfs_emit(buf, "%s\n", opts->NAME);            \
>> +}                                    \
>> +                                    \
>> +static ssize_t nvme_ctrl_##NAME##_store(struct device *dev,        \
>> +        struct device_attribute *attr, const char *buf, \
>> +        size_t count)                        \
>> +{                                    \
>> +    struct nvme_ctrl *ctrl = dev_get_drvdata(dev);            \
>> +                                    \
>> +    return nvme_dhchap_secret_store_common(ctrl, buf, count, cs);    \
>> +}                                    \
>> +                                    \
>> +static DEVICE_ATTR(NAME, S_IRUGO | S_IWUSR,                \
>> +    nvme_ctrl_##NAME##_show, nvme_ctrl_##NAME##_store); \
>>   -static DEVICE_ATTR(dhchap_ctrl_secret, S_IRUGO | S_IWUSR,
>> -    nvme_ctrl_dhchap_ctrl_secret_show, 
>> nvme_ctrl_dhchap_ctrl_secret_store);
>> +NVME_AUTH_DEVICE_ATTR(dhchap_secret, false);
>> +NVME_AUTH_DEVICE_ATTR(dhchap_ctrl_secret, true);
>>   #endif
>>     static struct attribute *nvme_dev_attrs[] = {
>
> Is it really worthwhile?
> These are just two sysfs attributes which are generalized that way, 
> and it's adding quite some boilerplate code to make it work.
>
> Plus I'll plan to rewrite authentication key handling to leverage 
> in-kernel keyrings once the TLS stuff has been accepted.
>
> So I'd rather not have this one. But might be convinced if someone has 
> a more compelling reason.
>
> Cheers,
>
> Hannes

let's drop this then, and merge first one ...

-ck



      reply	other threads:[~2023-06-05  8:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05  6:51 [PATCH V2 0/2] nvme: dhchap_secret code cleanup Chaitanya Kulkarni
2023-06-05  6:51 ` [PATCH V2 1/2] nvme: add generic helper to store secret Chaitanya Kulkarni
2023-06-05  7:52   ` Hannes Reinecke
2023-06-05 22:30   ` Sagi Grimberg
2023-06-06  3:24     ` Chaitanya Kulkarni
2023-06-06  6:43       ` Sagi Grimberg
2023-06-07  3:44         ` Chaitanya Kulkarni
2023-06-07  5:03         ` hch
2023-06-05  6:51 ` [PATCH V2 2/2] nvme-core: use macro defination to define dev attr Chaitanya Kulkarni
2023-06-05  7:55   ` Hannes Reinecke
2023-06-05  8:01     ` Chaitanya Kulkarni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84e8a7be-51e1-e743-97cd-71eea2d40da6@nvidia.com \
    --to=chaitanyak@nvidia.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).