From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030936AbbD1VFb (ORCPT ); Tue, 28 Apr 2015 17:05:31 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:32815 "EHLO mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965926AbbD1VFa (ORCPT ); Tue, 28 Apr 2015 17:05:30 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150428181203.35812.60474.stgit@dwillia2-desk3.amr.corp.intel.com> <20150428182417.35812.92834.stgit@dwillia2-desk3.amr.corp.intel.com> From: Andy Lutomirski Date: Tue, 28 Apr 2015 14:05:08 -0700 Message-ID: Subject: Re: [PATCH v2 01/20] e820, efi: add ACPI 6.0 persistent memory types To: Dan Williams Cc: linux-nvdimm , Ingo Molnar , Boaz Harrosh , Andrew Morton , "linux-kernel@vger.kernel.org" , Christoph Hellwig , Jens Axboe , Borislav Petkov , "H. Peter Anvin" , Matthew Wilcox , Thomas Gleixner , Linus Torvalds , Ross Zwisler Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 28, 2015 at 1:57 PM, Dan Williams wrote: > On Tue, Apr 28, 2015 at 1:49 PM, Andy Lutomirski wrote: >> On Tue, Apr 28, 2015 at 11:24 AM, Dan Williams wrote: >>> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c >>> index 11cc7d54ec3f..d38b53a7e9b2 100644 >>> --- a/arch/x86/kernel/e820.c >>> +++ b/arch/x86/kernel/e820.c >>> @@ -149,6 +149,7 @@ static void __init e820_print_type(u32 type) >>> case E820_UNUSABLE: >>> printk(KERN_CONT "unusable"); >>> break; >>> + case E820_PMEM: >>> case E820_PRAM: >>> printk(KERN_CONT "persistent (type %u)", type); >>> break; >> >> I'd kind of like to make it more clear what's going on here. It >> doesn't help that the spec chose poor names. >> >> How about "NVDIMM physical aperture" for E820_PMEM and "legacy >> persistent RAM" for E820_PRAM? > > The term "aperture" to me implies this BLK (mmio-windowed) mode of > accessing persistent media that the NFIT specification introduces. In > fact, those ranges are mapped E820_RESERVED. E820_PMEM really is a > memory range that happens to be persistent. Oh, I missed that. Yuck. What happens when you repartition one of these things? (Can you even do that?) > >> Otherwise this looks generaly sensible, although I don't really >> understand why e820_type_to_string and e820_print_type are different. > > e820_type_to_string() appears in /proc/iomem and seems to afford > being more descriptive than e820_print_type() that just scrolls by in > dmesg, but I'm just guessing. Can we change that? -- Andy Lutomirski AMA Capital Management, LLC