Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges
From: Linda Knippers
Date: Thu Jun 29 2017 - 18:50:07 EST
On 6/29/2017 6:43 PM, Dan Williams wrote:
On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers <linda.knippers@xxxxxxx> wrote:
On 06/29/2017 06:28 PM, Dan Williams wrote:
On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers <linda.knippers@xxxxxxx> wrote:
[..]
The /dev/pmem
device name just tells you that your block device is hosted by a
driver that knows how to handle persistent memory constraints, but any
other details about the nature of the address range need to come from
other sources of information, and potentially information sources that
the kernel does not know about.
I'm asking about the other source of information in this specific case
where we're exposing pmem devices that will never ever be persistent.
Before we add these devices, I think we should be able to tell the user
how they can know the properties of the underlying device.
The only way I can think to indicate this is with a platform + device
whitelist in a tool like ndctl. Where the tool says "yes, these
xyz-vendor DIMMs on this abc-vendor platform with this 123-version
BIOS" is a known good persistent configuration.
Doesn't the kernel know that something will never ever be persistent
because the NFIT type says NFIT_SPA_VDISK, NFIT_SPA_VCD, or NFIT_SPA_VOLATILE?
That's the case I'm asking about here. In this patch, you're adding support
for creating /dev/pmem devices for those address ranges. My question is
how the admin/user knows that those devices will never ever be persistent.
The parent region of the namespace will have a 'volatile' type:
# cat /sys/bus/nd/devices/region0/devtype
nd_volatile
If all I know is the /dev/pmem device name, how do I find that?
-- ljk
I don't think we need ndctl to know which vendors' hardware/firmware
actually works as advertised.
Certification stickers is what I was thinking, but I was missing your
direction question.