Messages in this thread | | | Subject | Re: BOOT_CS | From | (Eric W. Biederman) | Date | 22 Feb 2004 15:05:46 -0700 |
| |
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote: > > hpa@zytor.com (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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |