Messages in this thread | | | From | "Sourav Sen" <> | Subject | RE: [2.6.6 PATCH] Exposing EFI memory map | Date | Thu, 6 May 2004 21:55:35 +0530 |
| |
+ -----Original Message----- + From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com] + Sent: Thursday, May 06, 2004 8:39 PM + To: Sourav Sen + Cc: 'Matt Domsch'; matthew.e.tolentino@intel.com; + linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org; + tony.luck@intel.com + Subject: Re: [2.6.6 PATCH] Exposing EFI memory map + + + On Thursday 06 May 2004 7:20 am, Sourav Sen wrote: + > + 1) Why does userspace / humans need to know this? For + > + debugging firmware? + > + > Maybe. But the point I had in mind is, say for example + > memory diagnostics applications/exercisers which reads (Blind + > reads, without caring about contents) memory + > to uncover errors (single bit errors) can use + > this to know the usable ranges and map them thru /dev/mem and + > read those ranges. + + For this application, the EFI memory map isn't what you want. + It's a pretty good approximation today, but the day when we'll + be able to hot-add memory is fast approaching, and the EFI map + won't mention anything added after boot. We'll discover all + that via ACPI (on ia64). +
Why not also update the efi memory table on a hotplug :-) (Now also it gets modified a little on a call to efi_memmap_walk()). Otherwise clients of efi_memmap_walk() will also get stale information after a hotplug, isn't it (assuming they want to know about available physical ranges)?
Also, kernel may not exactly use all the memory added via hotplug and there may be some truncation (just as efi_memmap_walk() does today). And it isn't help us if we get to know about those extents. Additionally we get to know about various mmio ranges and other ranges thru that table -- may be useful opportunistically.
--Sourav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |