[dm-devel] Persistent memory interface

Dan Williams dan.j.williams at intel.com
Fri Jun 19 19:23:13 UTC 2015


On Fri, Jun 19, 2015 at 12:22 PM, Dan Williams <dan.j.williams at intel.com> wrote:
> On Fri, Jun 19, 2015 at 12:14 PM, Mikulas Patocka <mpatocka at redhat.com> wrote:
>>
>>
>> On Fri, 19 Jun 2015, Dan Williams wrote:
>>
>>> On Fri, Jun 19, 2015 at 9:33 AM, Mikulas Patocka <mpatocka at redhat.com> 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




More information about the dm-devel mailing list