All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@suse.de>,
	akpm@linux-foundation.org, Yinghai Lu <yhlu.kernel@gmail.com>,
	Chandramouli Narayanan <mouli@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol
Date: Thu, 18 Oct 2007 14:57:22 +0800	[thread overview]
Message-ID: <1192690642.21509.33.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <m1abqif5dp.fsf@ebiederm.dsl.xmission.com>

On Wed, 2007-10-17 at 03:38 -0600, Eric W. Biederman wrote:
> Well there actually is no reason to copy the current data into the
> zero page.  We really should just leave it where it is until the
> kernel has managed to bootstrap it's basic services.

I think it is safer to copy boot parameters to kernel BSS segment.
Because the kernel bootstrap process may overwrite the original memory
area of boot parameters.

> As for the setup data can we please remove the pointers. And just
> require the that the data items be appended one after each other
> in memory.  Then we would just need a field where we could
> report an offset to the binary data from where we loaded the
> 16bit code/data.  We could even specify the end by requiring
> that we fill in setup_move_size or something of that nature.

In this solution, we should also avoid conflict between the boot data
and kernel early bootstrap process. I think copy these boot data to some
place safe may be better. Such as memory area after _end.

> Beyond that we should provide the bootloaders enough information to
> know which information the kernel will overwrite before it consults
> the e820 map and other indicators of what memory is free.

There are several memory areas used by kernel bootstrap before e820 map
is consulted. You can refer to bad_addr for details. So I think it may
be not a stable/simple prototype to provide this information to
bootloader.

Best Regards,
Huang Ying

      reply	other threads:[~2007-10-18  6:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12  5:52 [PATCH -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol Huang, Ying
2007-10-15  1:47 ` Huang, Ying
2007-10-17  1:59 ` Huang, Ying
2007-10-17  8:25   ` Andi Kleen
2007-10-17  9:05     ` Huang, Ying
2007-10-17  9:24       ` Andi Kleen
2007-10-18  6:44         ` Huang, Ying
2007-10-17  9:38 ` Eric W. Biederman
2007-10-18  6:57   ` Huang, Ying [this message]

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=1192690642.21509.33.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mouli@linux.intel.com \
    --cc=yhlu.kernel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.