Rob Gittins <rob.gitt...@linux.intel.com> writes: >> > void (*commitpmem)(struct block_device *bdev, void *addr); >> >> Seems like this would benefit from a length argument as well, no? > > Yes. Great point. I will add that in.
Rob, taking it a step further, maybe a vectored interface would be more flexible. Something to consider, anyway. >> > Another area requiring extension is the need to be able to clear PMEM >> > errors. When data is fetched from errored PMEM it is marked with the >> > poison attribute. If the CPU attempts to access the data it causes a >> > machine check. How errors are cleared is hardware dependent and needs >> > to be handled by the specific device driver. The following function >> > in the block_device_operations vector would clear the correct range >> > of PMEM and put new data there. If the argument data is null or the >> > size is zero the driver is free to put any data in PMEM it wishes. >> > >> > void (*clearerrorpmem)(struct block_device *bdev, void *addr, >> > size_t len, void *data); > >> What is the size of data? > > clearerrorpmem as part of the process of clearing an error > can effectively write a buffer of data as part of the > clear process. If the len is zero or the data pointer is null then > only a error clear happens. So data would be of 'len' size, then? In other words, this would be a way to restore data that may have been there? > The existing partitioning mechanism was intended for small drives > and works best for a single fs/device. We are approaching NV-DIMMs > as if they were more like LUNs in storage arrays. Each range is > treated as a device. A range of an NV-DIMM could be partitioned if > someone wanted to do such a thing. OK, that clears things up, thanks. -Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/