Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751854AbdIKP4T (ORCPT ); Mon, 11 Sep 2017 11:56:19 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:32898 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbdIKP4D (ORCPT ); Mon, 11 Sep 2017 11:56:03 -0400 X-Google-Smtp-Source: AOwi7QBeS+lGANCnhuNN7MK1dNfiKM1LMyW0XZ7ddD2Oy89lXA6W+mudCrLgIeI+smO7CKugJyERpF7JLAZOz7QPA5E= MIME-Version: 1.0 In-Reply-To: <20170911144111.GA15556@redhat.com> References: <150169667935.39569.15808116323143633486.stgit@dwillia2-desk3.amr.corp.intel.com> <150169668989.39569.8174620146135008137.stgit@dwillia2-desk3.amr.corp.intel.com> <20170911144111.GA15556@redhat.com> From: Dan Williams Date: Mon, 11 Sep 2017 08:56:01 -0700 Message-ID: Subject: Re: [PATCH v3 2/2] dm: allow device-mapper to operate without dax support To: Mike Snitzer Cc: kbuild test robot , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , dm-devel@redhat.com, Bart Van Assche , Alasdair Kergon Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1652 Lines: 35 On Mon, Sep 11, 2017 at 7:41 AM, Mike Snitzer wrote: > On Wed, Aug 02 2017 at 1:58pm -0400, > Dan Williams wrote: > >> Rather than have device-mapper directly 'select DAX', let the fact that >> BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax >> support. We arrange for all the dax core routines to compile to nops >> when CONFIG_DAX=n. With that in place we can simply handle the >> alloc_dax() error as expected and ifdef out the other device-mapper-dax >> support code. >> >> Now, if dax is provided by a leaf driver that driver may only arrange to >> compile the dax core as a module. Since device-mapper dax support is >> consumed by the always-built-in portion of the device-mapper >> implementation we need to upgrade from DAX=m to DAX=y. > > I applied the patches and then got nervous once I dug in.. this last > paragraph makes little sense to me. "the always-built-in portion of the > device-mapper implementation" is why: DM core can happily be compiled as > a module (dm-mod.ko). > > And I'm not sure why you're referencing DAX related > drivers/md/dm-builtin.c, why are you attachd DM's DAX support to that? > I'm not seeing where that is actually happening. > > I don't see why DM's support for DAX would need to force DAX to be > builtin rather than just a module. > > Sorry I didn't get around to looking at this until now, but it seems you > went wrong along the way? Or maybe I'm just missing something? > No, my fault, I didn't track BLK_DEV_DM_BUILTIN correctly and we can safely make DAX a module when CONFIG_BLK_DEV_DM=m. I'll fix that up, thanks for the catch.