dax: refactor dax-fs into a generic provider of 'struct dax_device' instances
authorDan Williams <dan.j.williams@intel.com>
Tue, 11 Apr 2017 16:49:49 +0000 (09:49 -0700)
committerDan Williams <dan.j.williams@intel.com>
Thu, 13 Apr 2017 04:59:14 +0000 (21:59 -0700)
commit7b6be8444e0f0dd675b54d059793423d3c9b4c03
treeb2782a46dda7b03fac23216f873b1a6bf1df58cb
parent5f0694b300b9fb8409272c550418c22e0e57314a
dax: refactor dax-fs into a generic provider of 'struct dax_device' instances

We want dax capable drivers to be able to publish a set of dax
operations [1]. However, we do not want to further abuse block_devices
to advertise these operations. Instead we will attach these operations
to a dax device and add a lookup mechanism to go from block device path
to a dax device. A dax capable driver like pmem or brd is responsible
for registering a dax device, alongside a block device, and then a dax
capable filesystem is responsible for retrieving the dax device by path
name if it wants to call dax_operations.

For now, we refactor the dax pseudo-fs to be a generic facility, rather
than an implementation detail, of the device-dax use case. Where a "dax
device" is just an inode + dax infrastructure, and "Device DAX" is a
mapping service layered on top of that base 'struct dax_device'.
"Filesystem DAX" is then a mapping service that layers a filesystem on
top of that same base device. Filesystem DAX is associated with a
block_device for now, but perhaps directly to a dax device in the
future, or for new pmem-only filesystems.

[1]: https://lkml.org/lkml/2017/1/19/880

Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
drivers/Makefile
drivers/dax/Kconfig
drivers/dax/Makefile
drivers/dax/dax.c [deleted file]
drivers/dax/dax.h
drivers/dax/device-dax.h [new file with mode: 0644]
drivers/dax/device.c [new file with mode: 0644]
drivers/dax/pmem.c
drivers/dax/super.c [new file with mode: 0644]
include/linux/dax.h
tools/testing/nvdimm/Kbuild