From: Khalid Aziz <khalid_aziz@hp.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [PATCH] kexec on ia64
Date: Mon, 15 Nov 2004 22:14:51 +0000 [thread overview]
Message-ID: <1100556891.26292.42.camel@lyra.fc.hp.com> (raw)
In-Reply-To: <1100550721.26287.32.camel@lyra.fc.hp.com>
On Mon, 2004-11-15 at 14:15, Luck, Tony wrote:
> >Here is what I am working on next:
> >
> >1. Save EFI memory map before it is trimmed.
>
> This code has been "evolving" for a long time now, more layers
> get addded to solve each new problem. If you get time, please
> step back about a half-mile and take a look at the big picture
> and see you you can see a better way to do the scanning and
> trimming and re-scanning. The overall problem statement (ignore
> anything except complete granules, honour the command-line arguments
> max_mem/max_addr, allocate a temporary bitmap for bootmem) seems
> like it shouldn't require such complex code :-) You can add your
> own new requirement to not modify the original EFI tables so that
> they can be re-scanned by a new kernel after kexec (new kernel
> might have a different granule size).
>
> -Tony
Tony,
I definitely like this idea better. I have been talking to another
developer who is struggling with efi_mem_map_walk() trimming original
EFI memory map for "mem=" and "max_addr=". We have discussed separating
efi_mem_map_walk() into three separate routines, one to simply walk
memory map and compute the physical memory size without touching map,
one to trim memory map for granule size and one to trim memory map for
"mem=" and "max_addr=". This will allow us to save an untouched memory
map in between calls to these routines. Now that I know you guys are
open to something like this, we will pursue it further :)
--
Khalid
==================================
Khalid Aziz Linux and Open Source Lab
(970)898-9214 Hewlett-Packard
khalid_aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
next prev parent reply other threads:[~2004-11-15 22:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-15 20:32 [PATCH] kexec on ia64 Khalid Aziz
2004-11-15 21:15 ` Luck, Tony
2004-11-15 22:03 ` David Mosberger
2004-11-15 22:14 ` Khalid Aziz [this message]
2004-11-16 17:28 ` Khalid Aziz
2005-10-25 22:52 ` Khalid Aziz
2005-10-26 18:28 ` Gerald Pfeifer
2005-10-26 19:02 ` Luck, Tony
2005-10-26 20:25 ` Eric W. Biederman
2005-10-26 21:43 ` Luck, Tony
2005-10-26 21:49 ` Khalid Aziz
2005-10-26 23:21 ` Zou Nan hai
2005-10-27 7:10 ` Eric W. Biederman
2005-10-27 19:05 ` Khalid Aziz
2005-10-27 23:17 ` Zou Nan hai
2006-04-03 22:20 ` Khalid Aziz
2006-04-04 4:20 ` Andrew Morton
2006-04-04 6:07 ` [Fastboot] " Michael Ellerman
2006-04-05 16:11 ` Khalid Aziz
2006-04-04 18:13 ` [Fastboot] " Eric W. Biederman
2006-04-05 16:34 ` Khalid Aziz
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=1100556891.26292.42.camel@lyra.fc.hp.com \
--to=khalid_aziz@hp.com \
--cc=linux-ia64@vger.kernel.org \
/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