Re: test suite?

Re: test suite?

[Randy.Dunlap]

| From: Robert P. J. Day <rpjday@mindspring.com>
|
|   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

Re: test suite?

[Randy.Dunlap]

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

| | From: Robert P. J. Day <rpjday@mindspring.com>
| |
| |   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

Re: test suite?

[Hugh Dickins]

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

Re: test suite?

[Randy.Dunlap]

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

Re: test suite?

[William Lee Irwin III]

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

Re: test suite?

[Martin J. Bligh]

> 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.

test suite?

[Robert P. J. Day]

  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

Re: test suite?

[Sam Ravnborg]

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

Re: test suite?

[Robert P. J. Day]

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

Re: test suite?

[Cliff White]

> 
>   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 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/
> 

Re: test suite?

[Adrian Bunk]

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