Re: BOOT_CS

[Eric W. Biederman]

"H. Peter Anvin" <hpa@xxxxxxxxx> writes:

> Eric W. Biederman wrote:
> > hpa@xxxxxxxxx (H. Peter Anvin) writes:
> >
> >>Anyone happen to know of any legitimate reason not to reload %cs in
> >> head.S?
> > Other than the fact it is strongly rude and error prone to depend on
> > the contents of a global descriptor table you did not setup?
> >
> 
> We already do that, as you might have noticed (we set all the data registers to
> __BOOT_DS; CS is the only that is changed.)

Right and it would be a cleanup not to touch __BOOT_DS.  We have
already reloaded it in  arch/i386/boot/compressed/head.S anyway.

> > That is almost nice.  Care to export where the bottom of the page
> > tables or even better where the bottom of the kernel is for those
> > folks who want to place their ramdisk as low in memory as possible?
> >
> 
> The problem is that you don't know until it's too late, since it can depend on
> dynamic factors.  This is part of why your insistence of putting the ramdisk in
> the "most incorrect" position is simply wrong.

Nope.  On other architectures where the bootloader has access to
vmlinux this works just fine, all dynamic factors can be contained in
the bss.  We don't go very long before we reserve memory after all.
It is only on x86 where there is not enough information that it is
problematic. 

Putting the ramdisk right after the kernel (text + data + bss) is the
"most correct" position.  Anything else is likely to break when the
firmware changes.  This has already happened 2 or 3 times on x86.

When putting the ramdisk right after the kernel if anything breaks you
will notice it immediately, and the kernel will be fixed.

If I truly put an initrd at the top of memory the kernel would not
even be able to read the ramdisk.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/