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
On Wed, 2007-10-17 at 11:24 +0200, Andi Kleen wrote:
> > Can you tell me what that early reservation interface is? What I find in
> > x86_64 that does early memory allocation is alloc_low_page, which gets
> > non-conflict memory area through e820 map.
>
> It's a new interface I only recently
On Wed, 2007-10-17 at 11:24 +0200, Andi Kleen wrote:
Can you tell me what that early reservation interface is? What I find in
x86_64 that does early memory allocation is alloc_low_page, which gets
non-conflict memory area through e820 map.
It's a new interface I only recently wrote:
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
"Huang, Ying" <[EMAIL PROTECTED]> writes:
> This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
> adds an extensible boot parameter passing mechanism, export the boot
> parameters via sysfs.
>
> The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
> and i386.
>
"Huang, Ying" <[EMAIL PROTECTED]> writes:
> On Wed, 2007-10-17 at 10:25 +0200, Andi Kleen wrote:
> > "Huang, Ying" <[EMAIL PROTECTED]> writes:
> >
> > > Do you think it is a good idea to check the collision between setup data
> > > and memory area used during kernel boot through bootmem
On Wed, 2007-10-17 at 10:25 +0200, Andi Kleen wrote:
> "Huang, Ying" <[EMAIL PROTECTED]> writes:
>
> > Do you think it is a good idea to check the collision between setup data
> > and memory area used during kernel boot through bootmem allocator?
>
> You can't solve this through bootmem because
"Huang, Ying" <[EMAIL PROTECTED]> writes:
> Do you think it is a good idea to check the collision between setup data
> and memory area used during kernel boot through bootmem allocator?
You can't solve this through bootmem because x86-64 allocates memory
in several places before bootmem (using
Huang, Ying [EMAIL PROTECTED] writes:
Do you think it is a good idea to check the collision between setup data
and memory area used during kernel boot through bootmem allocator?
You can't solve this through bootmem because x86-64 allocates memory
in several places before bootmem (using
On Wed, 2007-10-17 at 10:25 +0200, Andi Kleen wrote:
Huang, Ying [EMAIL PROTECTED] writes:
Do you think it is a good idea to check the collision between setup data
and memory area used during kernel boot through bootmem allocator?
You can't solve this through bootmem because x86-64
Huang, Ying [EMAIL PROTECTED] writes:
On Wed, 2007-10-17 at 10:25 +0200, Andi Kleen wrote:
Huang, Ying [EMAIL PROTECTED] writes:
Do you think it is a good idea to check the collision between setup data
and memory area used during kernel boot through bootmem allocator?
You can't
Huang, Ying [EMAIL PROTECTED] writes:
This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
adds an extensible boot parameter passing mechanism, export the boot
parameters via sysfs.
The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
and i386.
This
On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
> Known Issues:
>
> - Where is safe to place the linked list of setup_data? Because the
> length of the linked list of setup_data is variable, it can not be
> copied into BSS segment of kernel as that of "zero page". We must
> find a
On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
Known Issues:
- Where is safe to place the linked list of setup_data? Because the
length of the linked list of setup_data is variable, it can not be
copied into BSS segment of kernel as that of zero page. We must
find a safe place
Hi, Peter and Andi,
Do you think this patch set is ready for merging? Otherwise what I can
do to make it ready?
Best Regards,
Huang Ying
On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
> This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
> adds an extensible boot
Hi, Peter and Andi,
Do you think this patch set is ready for merging? Otherwise what I can
do to make it ready?
Best Regards,
Huang Ying
On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote:
This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
adds an extensible boot
This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
adds an extensible boot parameter passing mechanism, export the boot
parameters via sysfs.
The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
and i386.
This patchset is based on the proposal of Peter Anvin.
This patchset defines a 32-bit boot protocol for i386/x86_64 platform,
adds an extensible boot parameter passing mechanism, export the boot
parameters via sysfs.
The patchset has been tested against 2.6.23-rc8-mm2 kernel on x86_64
and i386.
This patchset is based on the proposal of Peter Anvin.
18 matches
Mail list logo
