test suite?

| From: Robert P. J. Day <[email protected]>
|
|   i've noticed references to "test suites" for kernels, but
| is there any one-step convenient way to select every possible
| option for test-compiling a new kernel, just to see if it builds?
| perhaps an "everything" option?
|
|   and, related to that, should such a kernel theoretically
| work?  as in, are there any options that would be mutually
| exclusive that would cause such a build to fail?
|
| still thinking about reorganizing the overall option structure,

Hi,

I notice that you've already had a reply on this (use "make help", "make allmodconfig" or "make allyesconfig" etc.).

OSDL's PLM does this (make allmodconfig) for each new (2.5) kernel release and the results are posted at
http://www.osdl.org/archive/cherry/stability/
and also in the PLM web page interface.
The script that is used for this is at that same URL above. PLM is at http://www.osdl.org/cgi-bin/plm/ .

Has anyone tried to boot an 'allyesconfig' kernel? I'll give that a shot now.

HTH.

~Randy

On Fri, 24 Jan 2003, Randy.Dunlap wrote:

| | From: Robert P. J. Day <[email protected]>
| |
| |   i've noticed references to "test suites" for kernels, but
| | is there any one-step convenient way to select every possible
| | option for test-compiling a new kernel, just to see if it builds?
| | perhaps an "everything" option?
| |
| |   and, related to that, should such a kernel theoretically
| | work?  as in, are there any options that would be mutually
| | exclusive that would cause such a build to fail?

I tried this...see below.
Short answer is that the resulting kernel is considered too large, but I don't know by what.
Anyone, where is this kernel size limit coming from?

| | still thinking about reorganizing the overall option structure,
|
| Hi,
|
| I notice that you've already had a reply on this (use "make help",
| "make allmodconfig" or "make allyesconfig" etc.).
|
| OSDL's PLM does this (make allmodconfig) for each new (2.5) kernel
| release and the results are posted at
|   http://www.osdl.org/archive/cherry/stability/
| and also in the PLM web page interface.
| The script that is used for this is at that same URL above.
| PLM is at http://www.osdl.org/cgi-bin/plm/ .
|
| Has anyone tried to boot an 'allyesconfig' kernel?
| I'll give that a shot now.

On a dual-proc P4 x86 machine, with 2.5.59, I did 'make allyesconfig' and tried to build the kernel. There were several classes of problems.

a. many syntax errors (> 50 source files): disabled these configs

b. many linker errors (> 50 object files): disabled these configs
(mostly references to save_flags/restore_flags etc.)

c. One particular error implies that 2 frame buffer options are
mutually exclusive: linking hgafb and fbmem give 6 duplicate symbols (all of the form 'linux_logo*').

d. There were 4 cases of referenced symbols being discarded or being
outside of the referencing code section. I used Keith's 'reference_discarded.pl' script and fixed these (or tried to). I will post a separate email for these.

e. Now the only remaining error is this:
arch/i386/boot/tools/build -b arch/i386/boot/bootsect arch/i386/boot/setup arch/i386/boot/vmlinux.bin CURRENT >

    arch/i386/boot/bzImage

Root device is (3, 4)
Boot sector 512 bytes.
Setup is 4880 bytes.
System is 8384 kB
System is too big. Try using modules.
make[1]: *** [arch/i386/boot/bzImage] Error 1
make: *** [bzImage] Error 2

~Randy

See pg0 and pg1 in arch/i386/kernel/head.S. There's no technical reason (but well-justified resistance to bloat) why pg2... cannot be added, but you might find a few little adjustments needed to match elsewhere (if you want your testbuild kernel to boot).

Hugh

On Sat, 25 Jan 2003, Hugh Dickins wrote:

| On Fri, 24 Jan 2003, Randy.Dunlap wrote:
| > Anyone, where is this kernel size limit coming from?
| >   System is 8384 kB
| >   System is too big. Try using modules.
|
| See pg0 and pg1 in arch/i386/kernel/head.S.  There's no technical
| reason (but well-justified resistance to bloat) why pg2... cannot
| be added, but you might find a few little adjustments needed to
| match elsewhere (if you want your testbuild kernel to boot).

Thanks, Hugh.

Just after I sent that email, I said to myself:
um, maybe something about GDT, related to (max) 1-1 memory mapping.

No, I don't need to boot that kernel.
It was enough of a problem just to build it.

~Randy

It's actually a relatively annoying limit, as various boxen's MP tables ACPI tables etc. etc. are well above 8MB. At some point one of us should quash that issue permanently and dynamically map the things. IIRC Linux needs NUMA-Q boxen to get lynxers reflashed to move MP tables below 8MB to boot atm. mbligh can more accurate describe the pain involved there. As for the bzImage, don't bother supporting excess bloat.

All I can say is, "bring me the head of the first moron who shoves some table needed at boot-time above 4GB".

-- wli

One of these days, I just need to make it remap the MPS tables with set_fixmap instead, would be a damned sight easier. Was quicker just to hack the firmware at the time, but it's not the RightThingToDo.

M.