On Tue, 08 May 2007 22:15:21 -0700, "H. Peter Anvin" <[email protected]>
said:
> I believe the x86 setup tree is now finished. I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.
Hi!
Only tiny sparks^Wremarks, I'm afraid. ;)
I've briefly looked at the new code in arch/i386/boot and as far
as I can determine in a short amount of time all functionality is
basically there, with the exception of the 'scan' functionality for
bios modes. Maybe it is not needed anymore? I have used this
functionality to find non-standard modes recently (for a kernel
crash during boot).
Random remarks about config-differences:
The new code does not use VIDEO_SELECT and X86_SPEEDSTEP_SMI
(i386-only): both parts are always compiled in. The new code uses FB:
the old code allowed setting a graphics mode, even without FB support.
Shared config options that affect the code generation: EDD, RELOCATABLE,
FIRMWARE_EDID, and APM (i386-only). Some code also depends on X86_ELAN
and X86_VOYAGER.
Allnoconfig realmode kernel part increases by about 3.5 kb:
old x86_64: Boot sector 512 bytes. / Setup is 4737 bytes.
new x86_64: Setup is 8808 bytes (padded to 9216 bytes).
old i386: Boot sector 512 bytes. / Setup is 4842 bytes.
new i386: Setup is 8776 bytes (padded to 9216 bytes).
When all relevant options are enabled about 1.5 kb:
old x86_64: Boot sector 512 bytes. / Setup is 7394 bytes.
new x86_64: Setup is 9672 bytes (padded to 9728 bytes).
old i386: Boot sector 512 bytes. / Setup is 7649 bytes.
new i386: Setup is 9896 bytes (padded to 10240 bytes).
So the code explosion is not too bad. Although... it is helps quite a
bit that the old setup contains a chunk of slightly more than 3 kb of
zeros which has disappeared with the new code. On the other hand, the
new code provides a valuable debugging tool in the form of a printf
function.
$ size arch/i386/boot/setup.elf
text data bss dec hex filename
9768 96 6056 15920 3e30 setup.elf
How much memory should we expect to be available? Is the assert for
32 kb for text+data+bss in setup.ld reasonable? Is it guaranteed
that the bootloader stores the commandline after _end?
The amount of code that depends on config options is relatively small.
Would it make sense to just compile everything independent of config
options and determine what should be done at run-time? And/or separate
the bootcode related config-options and put them under EMBEDDED/TINY?
If space is not that much of an issue, could you imagine putting
the decompression/relocation/misc.c code in setup too? This would
make it easier to start thinking of a new kernel image format without
breaking bootloaders that use a bzImage in the intended way.
Good luck,
Alexander
--
Alexander van Heukelum
[email protected]
--
http://www.fastmail.fm - A fast, anti-spam email service.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
