All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Gurtovoy <maxg@mellanox.com>
To: Sagi Grimberg <sagi@grimberg.me>,
	<linux-nvme@lists.infradead.org>,
	"Keith Busch" <kbusch@kernel.org>
Subject: Re: [PATCH rfc 2/2] fabrics: allow user to pass hostname instead of traddr
Date: Wed, 25 Mar 2020 00:57:51 +0200	[thread overview]
Message-ID: <f7a199c9-355c-6913-ee2b-36f634785573@mellanox.com> (raw)
In-Reply-To: <1740e836-7dff-35eb-6e42-17b666faa8ec@grimberg.me>


On 3/24/2020 9:11 PM, Sagi Grimberg wrote:
>
>>>>>   static int connect_ctrl(struct nvmf_disc_rsp_page_entry *e)
>>>>>   {
>>>>>       char argstr[BUF_SIZE], *p;
>>>>> @@ -1230,6 +1283,13 @@ static int discover_from_conf_file(const 
>>>>> char *desc, char *argstr,
>>>>>           if (cfg.persistent && !cfg.keep_alive_tmo)
>>>>>               cfg.keep_alive_tmo = NVMF_DEF_DISC_TMO;
>>>>> +        if (cfg.hostname) {
>>>>> +            ret = hostname2traddr(&cfg);
>>>>> +            if (ret)
>>>>> +                goto out;
>>>>> +            cfg.hostname = NULL;
>>>>> +        }
>>>>> +
>>>>
>>>> I guess you add the NULL to check mutual exclusion later ?
>>>
>>> The NULL assignment here is because we are looping on the conf
>>> file entries which can have a different hostname. The other
>>> locations are a one-shot so this assignment is not needed.
>>>
>>>> Can we check it in build_options ?
>>>
>>> When we get a hostname we resolve the traddr which is what
>>> build_options needs (hostname not an option that is passed to
>>> the driver).
>>>
>>> Does that answer your question?
>>
>> I meant to prevent a user to send them both in the command line (no 
>> to send it to the driver).
>
> build_options is just converting options to an argstr, not sure its a
> good idea to move that there...

You right, I was just thinking out loud.

We can check it before calling the resolution function hostname2traddr.

.


_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2020-03-24 22:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24  9:03 [PATCH rfc 0/2] support ip resolution with hostnames Sagi Grimberg
2020-03-24  9:03 ` [PATCH rfc 1/2] fabrics: add fabrics_ prefix to fabrics operations Sagi Grimberg
2020-03-24  9:03 ` [PATCH rfc 2/2] fabrics: allow user to pass hostname instead of traddr Sagi Grimberg
2020-03-24  9:46   ` Max Gurtovoy
2020-03-24 16:21     ` Sagi Grimberg
2020-03-24 17:24       ` Max Gurtovoy
2020-03-24 19:11         ` Sagi Grimberg
2020-03-24 22:57           ` Max Gurtovoy [this message]
2020-04-01 19:39   ` Keith Busch
2020-04-01 20:33     ` Sagi Grimberg
2020-04-01 20:43       ` Keith Busch
2020-03-24  9:06 ` [PATCH rfc 0/2] support ip resolution with hostnames Sagi Grimberg
2020-04-01  6:03 ` Sagi Grimberg

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=f7a199c9-355c-6913-ee2b-36f634785573@mellanox.com \
    --to=maxg@mellanox.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.