All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: John Meneghini <jmeneghi@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
	kbusch@kernel.org, sagi@grimberg.me, loberman@redhat.com,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	emilne@redhat.com, bgurney@redhat.com
Subject: Re: [PATCH v2 2/3] nvme-multipath: add the NVME_MULTIPATH_PARAM config option
Date: Mon, 7 Apr 2025 17:01:24 +0200	[thread overview]
Message-ID: <20250407150124.GA12900@lst.de> (raw)
In-Reply-To: <f949d227-b3ba-48dc-8dab-d527b82e1246@redhat.com>

On Fri, Apr 04, 2025 at 06:28:10PM -0400, John Meneghini wrote:
>> So maybe invert the option to
>>
>> config NVME_MULTIPATH_DISABLE
>> 	bool "Allow overriding the default nvme-multipath parameter"
>
> So the question is: do you want the core_nvme.multipath parameter
> to be excluded by default, or included by default?

I can live with it either way.

> Keith and I agreed to call this CONFIG_NVME_DISBALE_MULTIPATH_PARAM.
> However during testing I realized that many of the default make 'config'
> rules would end up with CONFIG_NVME_DISBALE_MULTIPATH_PARAM=y,
> even if I set the config rule to "default n".
>
> For example:
>
>  make localmodconfig
>  make allmodconfig
>
> would end up with compiling out the core_nvme.multipath parameter and I
> don't think this is what we want.

Weird, how does that override the explicit default statement?

> How about something simple like this:
>
> +config NVME_ENABLE_MULTIPATH_PARAM
> +       bool "NVMe enable core_nvme.multipath param"
> +       depends on NVME_CORE && NVME_MULTIPATH
> +       default y

"default y" is the default, so it can be skipped.



  reply	other threads:[~2025-04-07 17:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-22 23:28 [PATCH v2 0/3] nvme: make core.nvme_multipath configurable John Meneghini
2025-03-22 23:28 ` [PATCH v2 1/3] nvme-multipath: change the NVME_MULTIPATH config option John Meneghini
2025-03-22 23:28 ` [PATCH v2 2/3] nvme-multipath: add the NVME_MULTIPATH_PARAM " John Meneghini
2025-04-03  4:35   ` Christoph Hellwig
2025-04-04 22:28     ` John Meneghini
2025-04-07 15:01       ` Christoph Hellwig [this message]
2025-04-14 20:19   ` Keith Busch
2025-03-22 23:28 ` [PATCH v2 3/3] nvme: update the multipath warning in nvme_init_ns_head John Meneghini
2025-03-28 17:29 ` [PATCH v2 0/3] nvme: make core.nvme_multipath configurable Keith Busch

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=20250407150124.GA12900@lst.de \
    --to=hch@lst.de \
    --cc=bgurney@redhat.com \
    --cc=emilne@redhat.com \
    --cc=jmeneghi@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=loberman@redhat.com \
    --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.