Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752656AbdGFCI5 (ORCPT ); Wed, 5 Jul 2017 22:08:57 -0400 Received: from mail-yb0-f177.google.com ([209.85.213.177]:35271 "EHLO mail-yb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbdGFCIz (ORCPT ); Wed, 5 Jul 2017 22:08:55 -0400 MIME-Version: 1.0 In-Reply-To: <1499303324.2042.7.camel@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> <595589CF.5010605@hpe.com> <1499297819.2042.5.camel@hpe.com> <1499303324.2042.7.camel@hpe.com> From: Dan Williams Date: Wed, 5 Jul 2017 19:08:54 -0700 Message-ID: Subject: Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges To: "Kani, Toshimitsu" Cc: "linux-kernel@vger.kernel.org" , "hch@lst.de" , "viro@zeniv.linux.org.uk" , "x86@kernel.org" , "mawilcox@microsoft.com" , "linux-nvdimm@lists.01.org" , "Knippers, Linda" , "linux-fsdevel@vger.kernel.org" , "jack@suse.cz" , jmoyer , Johannes Thumshirn 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: 991 Lines: 22 [ adding Jeff, and Johannes ] On Wed, Jul 5, 2017 at 6:17 PM, Kani, Toshimitsu wrote: > On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote: [..] >> We have symlinks in /dev/disk/by* to make it easier to identify >> storage devices, I think it makes sense to add udev rules for >> identifying volatile pmem and not try to differentiate this in the >> default kernel device name. > > I am not sure what might be a good way, but I am concerned because a > single block device naming do not represent both volatile and > persistent media today. We do have time to changes this if we find out this is critical. Maybe it's best to ask Linux distro folks what would be easier for them? Jeff, Johannes, any thoughts on whether we should produce a "/dev/vmemX" device when we know the backing memory range is volatile? In this patch everything shows up as /dev/pmemX and you need to look elsewhere in sysfs to find that the memory range is defined as volatile by the NFIT.