From: Dave Hansen <haveblue@us.ibm.com>
To: Sourav Sen <souravs@india.hp.com>
Cc: "'Greg KH'" <greg@kroah.com>,
Matt_Domsch@dell.com,
"'Matthew E Tolentino'" <matthew.e.tolentino@intel.com>,
linux-ia64@vger.kernel.org,
"'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>
Subject: RE: [2.6.6 PATCH] Exposing EFI memory map
Date: Wed, 12 May 2004 09:15:16 -0700 [thread overview]
Message-ID: <1084378516.14581.56.camel@nighthawk> (raw)
In-Reply-To: <00cb01c4380b$55c97bc0$39624c0f@india.hp.com>
On Wed, 2004-05-12 at 03:24, Sourav Sen wrote:
> 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.
If you expose the EFI memory map, then you'll be able to write memory
diagnostics that will work on any EFI-based machine.
If you expose the EFI memory map in an architecture-independent fashion,
then you'll be able to write diagnostics that will work on any *Linux*
machine, plus all of the EFI machines. Plus, by doing it first, you get
to greatly influence how the arch-independent stuff is done to make your
life the easiest.
Think /sys/system/devices/memory, not /sys/firmware/efi.
We're planning on doing this anyway for memory hotplug, so some of the
work and ideas are already there. I'd be happy to point you to some
past discussions and code on the subject.
-- Dave
next prev parent reply other threads:[~2004-05-12 16:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-06 8:52 [2.6.6 PATCH] Exposing EFI memory map Sourav Sen
2004-05-06 10:44 ` Christoph Hellwig
2004-05-06 11:59 ` Matthew Wilcox
2004-05-06 12:18 ` Arjan van de Ven
2004-05-06 13:27 ` Matthew Wilcox
2004-05-06 14:00 ` Dave Hansen
2004-05-06 14:09 ` Arjan van de Ven
2004-05-06 14:09 ` Christoph Hellwig
2004-05-06 12:46 ` Matt Domsch
2004-05-06 13:20 ` Sourav Sen
2004-05-06 15:08 ` Bjorn Helgaas
2004-05-06 16:25 ` Sourav Sen
2004-05-06 16:49 ` Dave Hansen
2004-05-06 16:40 ` Greg KH
2004-05-07 9:45 ` Sourav Sen
2004-05-07 21:49 ` Greg KH
2004-05-11 14:44 ` Sourav Sen
2004-05-11 15:42 ` Dave Hansen
2004-05-12 10:24 ` Sourav Sen
2004-05-12 16:15 ` Dave Hansen [this message]
2004-05-13 14:10 ` Sourav Sen
2004-05-13 15:32 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2004-05-06 9:18 Sourav Sen
2004-05-06 13:23 Luck, Tony
2004-05-06 16:14 Tolentino, Matthew E
2004-05-06 18:47 Tolentino, Matthew E
2004-05-06 18:57 ` Dave Hansen
2004-05-06 20:54 Tolentino, Matthew E
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1084378516.14581.56.camel@nighthawk \
--to=haveblue@us.ibm.com \
--cc=Matt_Domsch@dell.com \
--cc=greg@kroah.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.e.tolentino@intel.com \
--cc=souravs@india.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox