• Dan Williams's avatar
    dax: refactor dax-fs into a generic provider of 'struct dax_device' instances · 7b6be844
    Dan Williams authored
    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/880Suggested-by: default avatarChristoph Hellwig <hch@lst.de>
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    7b6be844
Kbuild 2.21 KB