On Tue, Feb 2, 2016 at 12:05 AM, Jared Hulbert <jaredeh(a)gmail.com> wrote:
Well... as CONFIG_BLOCK was not required with filemap_xip.c for a
decade. This CONFIG_BLOCK dependency is a result of an incremental
feature from a certain point of view ;)
The obvious 'driver' is physical RAM without a particular driver.
Remember please I'm talking about embedded. RAM measured in MiB and
funky one off hardware etc. In the embedded world there are lots of
ways that persistent memory has been supported in device specific ways
without the new fancypants NFIT and Intel instructions,so frankly
they don't fit in the PMEM stuff. Maybe they could be supported in
PMEM but not without effort to bring embedded players to the table.
Not sure what you're trying to say here. An ACPI NFIT only feeds the
generic libnvdimm device model. You don't need NFIT to get pmem.
The other drivers are the MTD drivers, probably as read-only for
But the paradigm there isn't so different from what PMEM looks like
with asymmetric read/write capabilities.
The filesystem I'm concerned with is AXFS
Which I've been planning on trying to merge again due to a recent
resurgence of interest. The device model for AXFS is... weird. It
can use one or two devices at a time of any mix of NOR MTD, NAND MTD,
block, and unmanaged physical memory. It's a terribly useful model
for embedded. Anyway AXFS is readonly so hacking in a read only
dax_fault_nodev() and dax_file_read() would work fine, looks easy
enough. But... it would be cool if similar small embedded focused RW
filesystems were enabled.
Are those also out of tree?
I don't expect you to taint DAX with design requirements for
stuff that it wasn't built for, nobody ends up happy in that case.
However, if enabling the filesystem to manage the bdev_direct_access()
interactions solves some of the "alternate device" problems you are
discussing here, then there is a chance we can accommodate both.
Sometimes that works.
So... Forget CONFIG_BLOCK=n entirely I didn't want that to be the
focus anyway. Does it help to support the weirder XFS and btrfs
device models to enable the filesystem to handle the
It's not clear that it does. We just clarified with xfs and ext4 that
we can really on get_blocks(). That solves the immediate concern with