Messages in this thread | | | From | "Sourav Sen" <> | Subject | RE: [2.6.6 PATCH] Exposing EFI memory map | Date | Thu, 6 May 2004 18:50:07 +0530 |
| |
Hi Matt,
+ -----Original Message----- + From: Matt Domsch [mailto:Matt_Domsch@dell.com] + On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote: + > The following simple patch creates a read-only file + > "memmap" under <mount point>/firmware/efi/ in sysfs + > and exposes the efi memory map thru it. + + I'm not generally opposed, but have a couple questions. + + 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.
+ + 2) Can the memory map output ever be larger than PAGE_SIZE (lower + limit is 4KB on x86)? If not, what guarantees that? If so, you need + your own read mechanism rather than the generic sysfs one. +
I don't have an answer right now. I'll investigate. Tony Luck also expressed similar concerns and suggested seq*() interfaces. I'll see how I can do that.
+ The one-value-per-file rule has an exception for an array of values of + the same type per Documentation/filesystems/sysfs.txt, which this + looks to adhere to. + + Thanks, + Matt + + -- + Matt Domsch + Sr. Software Engineer, Lead Engineer + Dell Linux Solutions linux.dell.com & www.dell.com/linux + Linux on Dell mailing lists @ http://lists.us.dell.com +
Thanks 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/
| |