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,
rday
On Wed, Jan 22, 2003 at 08:44:05AM -0500, Robert P. J. Day wrote:
>
> 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?
Try "make help" some day..
make allyesconfig
make allmodconfig
make allnoconfig <- Opposite of what you ask for.
Sam
On Wed, 22 Jan 2003, Sam Ravnborg wrote:
> On Wed, Jan 22, 2003 at 08:44:05AM -0500, Robert P. J. Day wrote:
> >
> > 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?
>
> Try "make help" some day..
>
> make allyesconfig
> make allmodconfig
> make allnoconfig <- Opposite of what you ask for.
>
> Sam
thanks for the info. i assume the condescension was no extra charge.
rday
>
> 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,
> rday
The OSDL's patch lifecycle manager (http://www.osdl.org/cgi-bin/plm )
does something like this. It does a series of builds include a few that
select most every option. So you could toss the patch into PLM and look at
the results of those test compiles. In particular, the 'Desktop' config
turns on a ton of stuff ( and almost always fails ;)
We also do a 'regress' build, where we do 'make defconfig' and
'make allmodconfig' and count the errors.
I don't think we have any more detailed docs, but the test report does include
the .config files we run.
cliffw
>
> -
> 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/
>
On Wed, Jan 22, 2003 at 08:44:05AM -0500, Robert P. J. Day wrote:
>
> 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?
It shouldn't be possible to select mutually exclusive options.
I'm using three .config's:
1. CONFIG_MODULES not set, everything else turned on
2. CONFIG_MODULES and CONFIG_HOTPLUG not set, everything else turned on
3. as much as possible modular
With 2.4.20 there are no compile errors with the first two and only two
errors at "depmod" with the third one (one of these two compile errors
is clearly pathological).
The bigger problem are unusual .config's, e.g. if you turn off common
things like CONFIG_PCI or CONFIG_NET.
Another example is that in 2.4.20 there's a problem with the compilation
of one specific net driver (fixed in 2.4.21-pre) if you select this
specific net driver and not additionally one or more of several other
net drivers.
Unfortunately there doesn't seem to be a good solution for this problem
that doesn't need O(n^2) .config's for n kernel options.
> still thinking about reorganizing the overall option structure,
> rday
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
| 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
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).
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
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.
On Sat, Jan 25, 2003 at 08:22:10PM +0000, Hugh Dickins wrote:
> 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).
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
> 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.
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.