On Fri, Jun 19, 2015 at 12:22 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > On Fri, Jun 19, 2015 at 12:14 PM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: >> >> >> On Fri, 19 Jun 2015, Dan Williams wrote: >> >>> On Fri, Jun 19, 2015 at 9:33 AM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: >>> > Hi >>> > >>> > I looked at the new the persistent memory block device driver >>> > (drivers/block/pmem.c and arch/x86/kernel/pmem.c) and it seems that the >>> > interface between them is incorrect. >>> > >>> > If I want to use persistent memory in another driver, for a different >>> > purpose, how can I make sure that that drivers/block/pmem.c doesn't attach >>> > to this piece of memory and export it? It seems not possible. >>> > drivers/block/pmem.c attaches to everything without regard that there may >>> > be other users of persistent memory. >>> >>> Simply partition the pmem device however you see fit and then >>> blkdev_get_by_path(<dev>, FMODE_EXCL, <holder>) the resulting >>> partition(s). >> >> But that still means accessing it through the block layer. >> >> I need to access persistent memory directly - map it into the kernel space >> and access it as mapped memory - and if I do it, it will fight with >> drivers/block/pmem.c over ownership of the memory :-( >> > > See the latest definition of struct block_device_operations in these > patches. We now have ->direct_access() in the 4.0 kernel and will > have ->rw_bytes() in the 4.2 kernel if you want to directly access the > memory published by a pmem device. I'll include you on the next rev of patches that add a kmap_atomic_pfn_t(): https://lkml.org/lkml/2015/6/5/802 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
