Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 28 Apr 2015 14:05:08 -0700 | Subject | Re: [PATCH v2 01/20] e820, efi: add ACPI 6.0 persistent memory types |
| |
On Tue, Apr 28, 2015 at 1:57 PM, Dan Williams <dan.j.williams@intel.com> wrote: > On Tue, Apr 28, 2015 at 1:49 PM, Andy Lutomirski <luto@amacapital.net> wrote: >> On Tue, Apr 28, 2015 at 11:24 AM, Dan Williams <dan.j.williams@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
| |