On Mon, Jan 23, 2017 at 8:00 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Sun, Jan 22, 2017 at 11:10:04PM -0800, Dan Williams wrote: >> How about we solve the copy_from_user() abuse first before we hijack >> this thread for some future feature that afaics has no patches posted >> yet. > > Solving copy_from_user abuse first sounds perfectly fine to me. But > please do so without abusing the block layer for persistent memory > access. Given that we don't have use cases for different pmem access > methods in a single OS image yet let's avoid introducing new ops > for now and just remove the copy_from_user abuse. The use case that we have now is distinguishing volatile vs persistent memory (brd vs pmem). I took a look at mtd layering approach and the main difference is that layers above the block layer do not appear to know anything about mtd specifics. For fs/dax.c we currently need some path to retrieve a dax anchor object through the block device. > In the longer run I like your dax_operations, but they need to be > separate from the block layer. I'll move them from block_device_operations to dax data hanging off of the bdev_inode, or is there a better way to go from bdev-to-dax? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
