Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751654AbdF2WnW (ORCPT ); Thu, 29 Jun 2017 18:43:22 -0400 Received: from mail-yw0-f175.google.com ([209.85.161.175]:34031 "EHLO mail-yw0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532AbdF2WnU (ORCPT ); Thu, 29 Jun 2017 18:43:20 -0400 MIME-Version: 1.0 In-Reply-To: <595580A6.9000004@hpe.com> References: <149875877608.10031.17813337234536358002.stgit@dwillia2-desk3.amr.corp.intel.com> <149875884190.10031.6179599135820559644.stgit@dwillia2-desk3.amr.corp.intel.com> <595552F5.5040008@hpe.com> <59556E37.80808@hpe.com> <595580A6.9000004@hpe.com> From: Dan Williams Date: Thu, 29 Jun 2017 15:43:19 -0700 Message-ID: Subject: Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges To: Linda Knippers Cc: "linux-nvdimm@lists.01.org" , Jan Kara , Matthew Wilcox , X86 ML , "linux-kernel@vger.kernel.org" , Al Viro , linux-fsdevel , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1831 Lines: 38 On Thu, Jun 29, 2017 at 3:35 PM, Linda Knippers wrote: > On 06/29/2017 06:28 PM, Dan Williams wrote: >> On Thu, Jun 29, 2017 at 3:12 PM, Linda Knippers 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 > 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.