All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>,
	dm-devel@redhat.com, linux-kernel@vger.kernel.org,
	Alasdair Kergon <agk@redhat.com>,
	linux-nvdimm@lists.01.org
Subject: Re: dm: enable opt-out of device-mapper dax support
Date: Tue, 1 Aug 2017 15:02:57 -0400	[thread overview]
Message-ID: <20170801190257.GA10033@redhat.com> (raw)
In-Reply-To: <150161113411.34055.9762658795237184307.stgit@dwillia2-desk3.amr.corp.intel.com>

On Tue, Aug 01 2017 at  2:12pm -0400,
Dan Williams <dan.j.williams@intel.com> wrote:

> Now that dax is no longer a default property of a block-device, i.e.
> ->direct_access() is not a block-device operation, we optionally enable
> device-mapper dax support with a new CONFIG_DM_DAX option.
> 
> All the dax operations helpers are moved to a new file,
> drivers/md/dm-dax.c, that is optionally compiled when CONFIG_DM_DAX=y.
> Otherwise, we stub out all the operations with NULL function pointers
> and nop wrappers for the core dax routines.
> 
> Cc: Alasdair Kergon <agk@redhat.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  drivers/md/Kconfig     |   14 +++
>  drivers/md/Makefile    |    1 
>  drivers/md/dm-dax.c    |  227 ++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/md/dm-dax.h    |   73 +++++++++++++++
>  drivers/md/dm-linear.c |   56 ------------
>  drivers/md/dm-snap.c   |    9 --
>  drivers/md/dm-stripe.c |   89 -------------------
>  drivers/md/dm-target.c |    7 -
>  drivers/md/dm.c        |  105 ++--------------------
>  drivers/md/dm.h        |   34 +++++++
>  10 files changed, 363 insertions(+), 252 deletions(-)
>  create mode 100644 drivers/md/dm-dax.c
>  create mode 100644 drivers/md/dm-dax.h
> 
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 4a249ee86364..bf27b435f7cd 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -200,7 +200,6 @@ config BLK_DEV_DM_BUILTIN
>  config BLK_DEV_DM
>  	tristate "Device mapper support"
>  	select BLK_DEV_DM_BUILTIN
> -	select DAX
>  	---help---
>  	  Device-mapper is a low level volume manager.  It works by allowing
>  	  people to specify mappings for ranges of logical sectors.  Various
> @@ -214,6 +213,19 @@ config BLK_DEV_DM
>  
>  	  If unsure, say N.
>  
> +config DM_DAX
> +	bool "Direct access (DAX) support"
> +	depends on BLK_DEV_DM
> +	default BLK_DEV_PMEM
> +	select DAX
> +	---help---
> +	  Enable DAX support for the device-mapper linear and stripe
> +	  targets for use with DAX capable block devices like /dev/pmemN.
> +	  If you have a DAX capable block device and have enabled
> +	  filesystem DAX support (CONFIG_FS_DAX), then say Y.
> +
> +	  If unsure, say N.
> +

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.

Mike
_______________________________________________
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: Mike Snitzer <snitzer@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>,
	dm-devel@redhat.com, linux-kernel@vger.kernel.org,
	Alasdair Kergon <agk@redhat.com>,
	linux-nvdimm@lists.01.org
Subject: Re: dm: enable opt-out of device-mapper dax support
Date: Tue, 1 Aug 2017 15:02:57 -0400	[thread overview]
Message-ID: <20170801190257.GA10033@redhat.com> (raw)
In-Reply-To: <150161113411.34055.9762658795237184307.stgit@dwillia2-desk3.amr.corp.intel.com>

On Tue, Aug 01 2017 at  2:12pm -0400,
Dan Williams <dan.j.williams@intel.com> wrote:

> Now that dax is no longer a default property of a block-device, i.e.
> ->direct_access() is not a block-device operation, we optionally enable
> device-mapper dax support with a new CONFIG_DM_DAX option.
> 
> All the dax operations helpers are moved to a new file,
> drivers/md/dm-dax.c, that is optionally compiled when CONFIG_DM_DAX=y.
> Otherwise, we stub out all the operations with NULL function pointers
> and nop wrappers for the core dax routines.
> 
> Cc: Alasdair Kergon <agk@redhat.com>
> Cc: Mike Snitzer <snitzer@redhat.com>
> Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  drivers/md/Kconfig     |   14 +++
>  drivers/md/Makefile    |    1 
>  drivers/md/dm-dax.c    |  227 ++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/md/dm-dax.h    |   73 +++++++++++++++
>  drivers/md/dm-linear.c |   56 ------------
>  drivers/md/dm-snap.c   |    9 --
>  drivers/md/dm-stripe.c |   89 -------------------
>  drivers/md/dm-target.c |    7 -
>  drivers/md/dm.c        |  105 ++--------------------
>  drivers/md/dm.h        |   34 +++++++
>  10 files changed, 363 insertions(+), 252 deletions(-)
>  create mode 100644 drivers/md/dm-dax.c
>  create mode 100644 drivers/md/dm-dax.h
> 
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 4a249ee86364..bf27b435f7cd 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -200,7 +200,6 @@ config BLK_DEV_DM_BUILTIN
>  config BLK_DEV_DM
>  	tristate "Device mapper support"
>  	select BLK_DEV_DM_BUILTIN
> -	select DAX
>  	---help---
>  	  Device-mapper is a low level volume manager.  It works by allowing
>  	  people to specify mappings for ranges of logical sectors.  Various
> @@ -214,6 +213,19 @@ config BLK_DEV_DM
>  
>  	  If unsure, say N.
>  
> +config DM_DAX
> +	bool "Direct access (DAX) support"
> +	depends on BLK_DEV_DM
> +	default BLK_DEV_PMEM
> +	select DAX
> +	---help---
> +	  Enable DAX support for the device-mapper linear and stripe
> +	  targets for use with DAX capable block devices like /dev/pmemN.
> +	  If you have a DAX capable block device and have enabled
> +	  filesystem DAX support (CONFIG_FS_DAX), then say Y.
> +
> +	  If unsure, say N.
> +

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.

Mike

WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Bart Van Assche <Bart.VanAssche-Sjgp3cTcYWE@public.gmane.org>,
	dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Alasdair Kergon <agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
Subject: Re: dm: enable opt-out of device-mapper dax support
Date: Tue, 1 Aug 2017 15:02:57 -0400	[thread overview]
Message-ID: <20170801190257.GA10033@redhat.com> (raw)
In-Reply-To: <150161113411.34055.9762658795237184307.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

On Tue, Aug 01 2017 at  2:12pm -0400,
Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> Now that dax is no longer a default property of a block-device, i.e.
> ->direct_access() is not a block-device operation, we optionally enable
> device-mapper dax support with a new CONFIG_DM_DAX option.
> 
> All the dax operations helpers are moved to a new file,
> drivers/md/dm-dax.c, that is optionally compiled when CONFIG_DM_DAX=y.
> Otherwise, we stub out all the operations with NULL function pointers
> and nop wrappers for the core dax routines.
> 
> Cc: Alasdair Kergon <agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Reported-by: Bart Van Assche <Bart.VanAssche-Sjgp3cTcYWE@public.gmane.org>
> Signed-off-by: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/md/Kconfig     |   14 +++
>  drivers/md/Makefile    |    1 
>  drivers/md/dm-dax.c    |  227 ++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/md/dm-dax.h    |   73 +++++++++++++++
>  drivers/md/dm-linear.c |   56 ------------
>  drivers/md/dm-snap.c   |    9 --
>  drivers/md/dm-stripe.c |   89 -------------------
>  drivers/md/dm-target.c |    7 -
>  drivers/md/dm.c        |  105 ++--------------------
>  drivers/md/dm.h        |   34 +++++++
>  10 files changed, 363 insertions(+), 252 deletions(-)
>  create mode 100644 drivers/md/dm-dax.c
>  create mode 100644 drivers/md/dm-dax.h
> 
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 4a249ee86364..bf27b435f7cd 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -200,7 +200,6 @@ config BLK_DEV_DM_BUILTIN
>  config BLK_DEV_DM
>  	tristate "Device mapper support"
>  	select BLK_DEV_DM_BUILTIN
> -	select DAX
>  	---help---
>  	  Device-mapper is a low level volume manager.  It works by allowing
>  	  people to specify mappings for ranges of logical sectors.  Various
> @@ -214,6 +213,19 @@ config BLK_DEV_DM
>  
>  	  If unsure, say N.
>  
> +config DM_DAX
> +	bool "Direct access (DAX) support"
> +	depends on BLK_DEV_DM
> +	default BLK_DEV_PMEM
> +	select DAX
> +	---help---
> +	  Enable DAX support for the device-mapper linear and stripe
> +	  targets for use with DAX capable block devices like /dev/pmemN.
> +	  If you have a DAX capable block device and have enabled
> +	  filesystem DAX support (CONFIG_FS_DAX), then say Y.
> +
> +	  If unsure, say N.
> +

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.

Mike

  reply	other threads:[~2017-08-01 19:00 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 [this message]
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
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=20170801190257.GA10033@redhat.com \
    --to=snitzer@redhat.com \
    --cc=Bart.VanAssche@wdc.com \
    --cc=agk@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    /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.