On Tue, Apr 28, 2015 at 1:57 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Tue, Apr 28, 2015 at 1:49 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Tue, Apr 28, 2015 at 11:24 AM, Dan Williams <dan.j.willi...@intel.com> >> 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 -- 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/
