Message-Id: <1178806235.18785.1189115515@webmail.messagingengine.com>
Date:	Thu, 10 May 2007 16:10:35 +0200
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"H. Peter Anvin" <hpa@...or.com>,
	"Antonino A. Daplas" <adaplas@...il.com>,
	"Andi Kleen" <ak@...e.de>, "Andrew Morton" <akpm@...l.org>,
	"Matt Domsch" <Matt_Domsch@...l.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Vivek Goyal" <vgoyal@...ibm.com>,
	"James Bottomley" <James.Bottomley@...senPar>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Alexander van Heukelum" <heukelum@...lshack.com>
Subject: Re: x86 setup rewrite tree ready for flamage^W review

On Tue, 08 May 2007 22:15:21 -0700, "H. Peter Anvin" <hpa@...or.com>
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
  heukelum@...tmail.fm

-- 
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists