On Tue, 23 Oct 2007 16:55:13 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Andi Kleen wrote:
> >
> > With the early reserve code in
> > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve
> > and
> > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc
> > this could be
On Tue, 2007-10-23 at 16:55 -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> > With the early reserve code in
> > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve
> > and
> > ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc
> > this could be likely done cleaner.
>
Andi Kleen wrote:
With the early reserve code in
ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-reserve
and
ftp://firstfloor.org/pub/ak/x86_64/quilt/patches/early-alloc
this could be likely done cleaner.
Indeed it could. For i386, the equivalent code would have another
significant
H. Peter Anvin wrote:
> Furthermore, on looking through the code again, I see a bunch of
> "init_pg_tables_end + setup_data_len" which really is ugly.
Yeah, that's what I'm objecting to.
>> What are the alignment rules for this structure? Is it always 64-bit
>> aligned? What about the relations
On Wednesday 24 October 2007 00:08:32 Jeremy Fitzhardinge wrote:
> Huang, Ying wrote:
> > This patch add a field of 64-bit physical pointer to NULL terminated
> > single linked list of struct setup_data to real-mode kernel
> > header. This is used as a more extensible boot parameters passing
> > me
Jeremy Fitzhardinge wrote:
As a general comment, I can't say I'm thrilled about sticking the copied
setup data at the end of the initial pagetables. This is already a
fairly complex area, and changing it touches a surprisingly large number
of places. I wonder if there isn't a better way to dea
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
No, he doesn't. The boot protocol version is communication between
the boot loader and the kernel (specifically, it is communication FROM
the kernel TO the bootloader), not between internal bits of the
kernel. Th
So the bootloader will only fi
H. Peter Anvin wrote:
> No, he doesn't. The boot protocol version is communication between
> the boot loader and the kernel (specifically, it is communication FROM
> the kernel TO the bootloader), not between internal bits of the
> kernel. Th
So the bootloader will only fill out fields the kerne
Jeremy Fitzhardinge wrote:
1:
+ movl boot_params - __PAGE_OFFSET + SETUP_DATA_POINTER,%ebp
You need to check the boot protocol version before looking at this pointer.
No, he doesn't. The boot protocol version is communication between the
boot loader and the kernel (specifically, it
Huang, Ying wrote:
> This patch add a field of 64-bit physical pointer to NULL terminated
> single linked list of struct setup_data to real-mode kernel
> header. This is used as a more extensible boot parameters passing
> mechanism.
>
As a general comment, I can't say I'm thrilled about stickin
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
arch/x86/boot/header.S |6
11 matches
Mail list logo
