On Mon, Sep 11, 2017 at 7:41 AM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > On Wed, Aug 02 2017 at 1:58pm -0400, > Dan Williams <dan.j.williams@xxxxxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
