All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
	"agk@redhat.com" <agk@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"snitzer@redhat.com" <snitzer@redhat.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: dm: enable opt-out of device-mapper dax support
Date: Tue, 1 Aug 2017 14:19:50 -0700	[thread overview]
Message-ID: <CAPcyv4gjN8AykVO2RoNorR0mOPOXVzg=8s3+mhueGF5+v0-mHA@mail.gmail.com> (raw)
In-Reply-To: <1501621491.2475.20.camel@wdc.com>

On Tue, Aug 1, 2017 at 2:04 PM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> On Tue, 2017-08-01 at 13:59 -0700, Dan Williams wrote:
>> On Tue, Aug 1, 2017 at 12:45 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>> > On Tue, Aug 1, 2017 at 12:02 PM, Mike Snitzer <snitzer@redhat.com> wrote:
>> > > On Tue, Aug 01 2017 at  2:12pm -0400,
>> > > Dan Williams <dan.j.williams@intel.com> wrote:
>> > > > [ ... ]
>> > >
>> > > I'm questioning the need to have yet another Kbuild CONFIG option.  If
>> > > the user has enabled CONFIG_BLK_DEV_PMEM and CONFIG_FS_DAX (DAX already
>> > > gets selected by CONFIG_FS_DAX) then shouldn't the DM capabilities just
>> > > be enabled?
>> > >
>> > > Guess I'm just skeptical of: why do we want to move to a model where
>> > > users need to opt-in to DM support for DAX?
>> > >
>> > > I also _really_ don't like each target's DAX support being colocated in
>> > > drivers/md/dm-dax.c
>> > >
>> > > This all looks and feels like a serious step backwards.
>> >
>> > Ok, you want ifdef'd sections of DAX code in each target and make
>> > DM_DAX a silent option that gets enabled with BLK_DEV_PMEM, anything
>> > else?
>>
>> Actually, no, I was thrown off by Bart's suggestion to move code
>> around. I can handle this all by deleting "select DAX" and adding more
>> stubbed out dax helpers.
>
> Hello Mike and Dan,
>
> How about one *-dax.c file per *.c dm file that has to be modified to add DAX support?
> I think that approach would avoid collocation of code for different targets in a
> single dm-dax.c file and would also avoid that #ifdef CONFIG_DAX statements have to
> be added. This approach is orthogonal to removal of CONFIG_DM_DAX.

You're free to send an alternative approach, but the new ifdefs in
include/linux/dax.h seem to be the cleanest option to remove dax text
size when the device-mapper dax support is not needed.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "snitzer@redhat.com" <snitzer@redhat.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"agk@redhat.com" <agk@redhat.com>
Subject: Re: dm: enable opt-out of device-mapper dax support
Date: Tue, 1 Aug 2017 14:19:50 -0700	[thread overview]
Message-ID: <CAPcyv4gjN8AykVO2RoNorR0mOPOXVzg=8s3+mhueGF5+v0-mHA@mail.gmail.com> (raw)
In-Reply-To: <1501621491.2475.20.camel@wdc.com>

On Tue, Aug 1, 2017 at 2:04 PM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> On Tue, 2017-08-01 at 13:59 -0700, Dan Williams wrote:
>> On Tue, Aug 1, 2017 at 12:45 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>> > On Tue, Aug 1, 2017 at 12:02 PM, Mike Snitzer <snitzer@redhat.com> wrote:
>> > > On Tue, Aug 01 2017 at  2:12pm -0400,
>> > > Dan Williams <dan.j.williams@intel.com> wrote:
>> > > > [ ... ]
>> > >
>> > > I'm questioning the need to have yet another Kbuild CONFIG option.  If
>> > > the user has enabled CONFIG_BLK_DEV_PMEM and CONFIG_FS_DAX (DAX already
>> > > gets selected by CONFIG_FS_DAX) then shouldn't the DM capabilities just
>> > > be enabled?
>> > >
>> > > Guess I'm just skeptical of: why do we want to move to a model where
>> > > users need to opt-in to DM support for DAX?
>> > >
>> > > I also _really_ don't like each target's DAX support being colocated in
>> > > drivers/md/dm-dax.c
>> > >
>> > > This all looks and feels like a serious step backwards.
>> >
>> > Ok, you want ifdef'd sections of DAX code in each target and make
>> > DM_DAX a silent option that gets enabled with BLK_DEV_PMEM, anything
>> > else?
>>
>> Actually, no, I was thrown off by Bart's suggestion to move code
>> around. I can handle this all by deleting "select DAX" and adding more
>> stubbed out dax helpers.
>
> Hello Mike and Dan,
>
> How about one *-dax.c file per *.c dm file that has to be modified to add DAX support?
> I think that approach would avoid collocation of code for different targets in a
> single dm-dax.c file and would also avoid that #ifdef CONFIG_DAX statements have to
> be added. This approach is orthogonal to removal of CONFIG_DM_DAX.

You're free to send an alternative approach, but the new ifdefs in
include/linux/dax.h seem to be the cleanest option to remove dax text
size when the device-mapper dax support is not needed.

  reply	other threads:[~2017-08-01 21:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-01 18:12 [PATCH] dm: enable opt-out of device-mapper dax support Dan Williams
2017-08-01 18:12 ` Dan Williams
2017-08-01 18:12 ` Dan Williams
2017-08-01 19:02 ` Mike Snitzer
2017-08-01 19:02   ` Mike Snitzer
2017-08-01 19:02   ` Mike Snitzer
2017-08-01 19:45   ` Dan Williams
2017-08-01 19:45     ` Dan Williams
2017-08-01 19:45     ` Dan Williams
2017-08-01 20:59     ` Dan Williams
2017-08-01 20:59       ` Dan Williams
2017-08-01 20:59       ` Dan Williams
2017-08-01 21:04       ` Bart Van Assche
2017-08-01 21:04         ` Bart Van Assche
2017-08-01 21:04         ` Bart Van Assche
2017-08-01 21:19         ` Dan Williams [this message]
2017-08-01 21:19           ` Dan Williams
2017-08-01 22:47 ` [PATCH v2] dm: allow device-mapper to operate without " Dan Williams
2017-08-01 22:47   ` Dan Williams
2017-08-01 22:47   ` Dan Williams
2017-08-02 16:02   ` kbuild test robot
2017-08-02 16:02     ` kbuild test robot
2017-08-02 20:44   ` kbuild test robot
2017-08-02 20:44     ` kbuild test robot
2017-08-02 20:44     ` kbuild test robot
2017-08-02  1:40 ` [PATCH] dm: enable opt-out of device-mapper " kbuild test robot
2017-08-02  1:40   ` kbuild test robot
2017-08-02  1:40   ` kbuild test robot
2017-08-02  1:48 ` kbuild test robot
2017-08-02  1:48   ` kbuild test robot
2017-08-02  1:48   ` kbuild test robot

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='CAPcyv4gjN8AykVO2RoNorR0mOPOXVzg=8s3+mhueGF5+v0-mHA@mail.gmail.com' \
    --to=dan.j.williams@intel.com \
    --cc=Bart.VanAssche@wdc.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=snitzer@redhat.com \
    /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.