Why can't Johnny compile?

Why can't Johnny compile?

[Dan Kegel]

john slee <indigoid@higherplane.net> wrote:
> On Thu, Nov 14, 2002 at 10:58:09PM -0500, Patrick Finnegan wrote:
>> It'd be nice if people simply tried compiling a patched kernel (all
>> affected modules) before they submitted the patch, I'm betting you'd catch
>> a lot of typos.  Also, compiling _everything_, even as a module, at
>> least once before sumbitting the patch would probably help.
> 
> thats fine if there is an all-compiling kernel release out there.  right
> now 2.5-bk is far from it.  last i checked allmodconfig (a couple of
> days ago) there was major breakage all over llc, scsi, video, sound, ...
> which kinda masks any breakages you might have introduced. 

Hrmph.  Y'know, maybe it's time for us to collectively put our
feet down, get 2.5-linus to the point where everything compiles,
and keep it there.  After all, we are supposedly trying to
*stabilize* 2.5.  It isn't stable if it doesn't compile...

- Dan

Re: Why can't Johnny compile?

[Jeff Garzik]

Dan Kegel wrote:

> john slee  wrote:
>
> > now 2.5-bk is far from it.  last i checked allmodconfig (a couple of
> > days ago) there was major breakage all over llc, scsi, video, sound, ...
> > which kinda masks any breakages you might have introduced.
>
> Hrmph.  Y'know, maybe it's time for us to collectively put our
> feet down, get 2.5-linus to the point where everything compiles,
> and keep it there.  After all, we are supposedly trying to
> *stabilize* 2.5.  It isn't stable if it doesn't compile...


Most of the stuff that doesn't compile (or link) is typically stuff that 
is lesser used, or never used.  A lot of the don't-compile complaints 
seem to be vocal-minority type complaints or "why can't I build _every_ 
module in the kernel?" complaints.  Ref allmodconfig, above.

If people want to get rivafb or an ancient ISA net driver building 
again... patches welcome.  But I don't think calls for the kernel to 
compile 100 percent of the drivers is realistic or even reasonable. 
Some of the APIs, particularly SCSI, are undergoing API stabilization. 
And SCSI is an excellent example of drivers where 
I-dont-have-test-hardware patches to fix compilation may miss subtle 
problems -- and then six months later when the compileable-but-broken 
SCSI driver is used by a real user, we have to spend more time in the 
long run tracking down the problem.

But like I said, patches welcome.

	Jeff

Re: Why can't Johnny compile?

[Patrick Finnegan]

On Sat, 16 Nov 2002, Jeff Garzik wrote:

> Most of the stuff that doesn't compile (or link) is typically stuff that
> is lesser used, or never used.  A lot of the don't-compile complaints
> seem to be vocal-minority type complaints or "why can't I build _every_
> module in the kernel?" complaints.  Ref allmodconfig, above.
>
> If people want to get rivafb or an ancient ISA net driver building
> again... patches welcome.  But I don't think calls for the kernel to
> compile 100 percent of the drivers is realistic or even reasonable.
> Some of the APIs, particularly SCSI, are undergoing API stabilization.
> And SCSI is an excellent example of drivers where
> I-dont-have-test-hardware patches to fix compilation may miss subtle
> problems -- and then six months later when the compileable-but-broken
> SCSI driver is used by a real user, we have to spend more time in the
> long run tracking down the problem.

Wouldn't it then seem reasonable to remove things from the kernel that
have been broken for a long time, and no one seems to care enough to fix?
I know of at least one driver (IOmega Buz v4l) that seems to have fallen
into disrepair possibly since before 2.4.0, and as far as I know has not
been repaired since then.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

Re: Why can't Johnny compile?

[Jeff Garzik]

Patrick Finnegan wrote:

> Wouldn't it then seem reasonable to remove things from the kernel that
> have been broken for a long time, and no one seems to care enough to fix?
> I know of at least one driver (IOmega Buz v4l) that seems to have fallen
> into disrepair possibly since before 2.4.0, and as far as I know has not
> been repaired since then.



That's really a matter of taste... a lot of Linux hackers seem to enjoy 
retrocomputing and keeping old things around just in case.  Just in case 
somebody sees you post, for example, and gets motivated to fix IOmega 
Buz :)  Some things do get removed though, every now and then.

We have CONFIG_OBSOLETE as a pseudo-config option around which we may 
deprecate drivers.  If a major version or two passes with no one 
complaining, we can remove the driver then...

	Jeff

Re: Why can't Johnny compile?

[William Lee Irwin III]

On Sat, 16 Nov 2002, Jeff Garzik wrote:
>> If people want to get rivafb or an ancient ISA net driver building
>> again... patches welcome.  But I don't think calls for the kernel to
>> compile 100 percent of the drivers is realistic or even reasonable.
>> Some of the APIs, particularly SCSI, are undergoing API stabilization.
[snip]

On Sat, Nov 16, 2002 at 01:04:35AM -0500, Patrick Finnegan wrote:
> Wouldn't it then seem reasonable to remove things from the kernel that
> have been broken for a long time, and no one seems to care enough to fix?
> I know of at least one driver (IOmega Buz v4l) that seems to have fallen
> into disrepair possibly since before 2.4.0, and as far as I know has not
> been repaired since then.

A lot of driver writers probably aren't going to even start updating
until the stable release is released. IIRC there are many vendors etc.
who focus exclusively on stable kernel releases, and who will let their
code (e.g. drivers) bitrot the entire way through the development cycle.

And there is plenty of code that is being updated now for the first
time since 2.0.x, and some arches that haven't merged since before 2.4.0

Bill

Re: Why can't Johnny compile?

[Ralf Baechle]

On Sat, Nov 16, 2002 at 01:04:35AM -0500, Patrick Finnegan wrote:

> Wouldn't it then seem reasonable to remove things from the kernel that
> have been broken for a long time, and no one seems to care enough to fix?
> I know of at least one driver (IOmega Buz v4l) that seems to have fallen
> into disrepair possibly since before 2.4.0, and as far as I know has not
> been repaired since then.

On a few opportunities when I removed broken features from the MIPS
kernel that was what it took to trigger somebody to fix it.

  Ralf

Re: Why can't Johnny compile?

[Kai Henningsen]

jgarzik@pobox.com (Jeff Garzik)  wrote on 16.11.02 in <3DD5DC77.2010406@pobox.com>:

> Most of the stuff that doesn't compile (or link) is typically stuff that
> is lesser used, or never used.  A lot of the don't-compile complaints
> seem to be vocal-minority type complaints or "why can't I build _every_
> module in the kernel?" complaints.  Ref allmodconfig, above.

So maybe there should be a list of config symbols to turn off (preferrably  
automatically) after allmodconfig or so, a "we know this is broken" list.

MfG Kai

Re: Why can't Johnny compile?

[Arnaldo Carvalho de Melo]

Em Sat, Nov 16, 2002 at 11:47:00AM +0200, Kai Henningsen escreveu:
> jgarzik@pobox.com (Jeff Garzik)  wrote on 16.11.02 in <3DD5DC77.2010406@pobox.com>:
> 
> > Most of the stuff that doesn't compile (or link) is typically stuff that
> > is lesser used, or never used.  A lot of the don't-compile complaints
> > seem to be vocal-minority type complaints or "why can't I build _every_
> > module in the kernel?" complaints.  Ref allmodconfig, above.
> 
> So maybe there should be a list of config symbols to turn off (preferrably  
> automatically) after allmodconfig or so, a "we know this is broken" list.

Humm, I've been playing with this, if you're willing to add this feature to
kbuild, I'll be happy to provide such a list, even with short explanation
on why it is broken (dma, cli/sti, schedule_task, etc). In fact I'll probably
have it anyway and do a grep -vf...

- Arnaldo

Re: Why can't Johnny compile?

[john slee]

> If people want to get rivafb or an ancient ISA net driver building 
> again... patches welcome.  But I don't think calls for the kernel to 

yep, someone is maintaining ewrk3 again now :-), or at least i have seen
a couple of patches submitted

> compile 100 percent of the drivers is realistic or even reasonable. 
> Some of the APIs, particularly SCSI, are undergoing API stabilization. 

the api stabilization should have been happening months ago, in view of
the october freeze

> And SCSI is an excellent example of drivers where 
> I-dont-have-test-hardware patches to fix compilation may miss subtle 
> problems -- and then six months later when the compileable-but-broken 
> SCSI driver is used by a real user, we have to spend more time in the 
> long run tracking down the problem.

certainly, and sometimes i wonder if there could be a better way (than
#error or #warning) to tag things as known broken.  currently people use
#error during compile, but i'd like to see it show up in menuconfig
somehow.

been thinking about it, but i haven't thought of a palatable solution
yet.  keeping the tag in the source files (as it is now) is probably a
good idea, but is suboptimal for external tools.  menuconfig doesn't
want to know about the actual source files

j.

-- 
toyota power: http://indigoid.net/

Re: Why can't Johnny compile?

[Jeff Garzik]

john slee wrote:

> >If people want to get rivafb or an ancient ISA net driver building
> >again... patches welcome.  But I don't think calls for the kernel to
>
>
> yep, someone is maintaining ewrk3 again now :-), or at least i have seen
> a couple of patches submitted


hehe, yep, in fact there is an ewrk3 patch I still need to merge :)

> >compile 100 percent of the drivers is realistic or even reasonable.
> >Some of the APIs, particularly SCSI, are undergoing API stabilization.
>
>
> the api stabilization should have been happening months ago, in view of
> the october freeze


october freeze was for major features, not minor incremental tweaks...


> >And SCSI is an excellent example of drivers where
> >I-dont-have-test-hardware patches to fix compilation may miss subtle
> >problems -- and then six months later when the compileable-but-broken
> >SCSI driver is used by a real user, we have to spend more time in the
> >long run tracking down the problem.
>
>
> certainly, and sometimes i wonder if there could be a better way (than
> #error or #warning) to tag things as known broken.  currently people use
> #error during compile, but i'd like to see it show up in menuconfig
> somehow.


I respectfully disagree...  I think if these sort of FIXMEs show up in 
menuconfig, you're not only cluttering up menuconfig, you also moving 
past the level of programmer to the sysadmin/power-user level.  That 
seems like it would generate more bug reports than useful work.

About the only thing WRT menuconfig I would be ok with is commenting out 
majorly broken drivers until they are fixed...

	Jeff

Re: Why can't Johnny compile?

[Arnaldo Carvalho de Melo]

Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
> john slee wrote:
> >#error or #warning) to tag things as known broken.  currently people use
> >#error during compile, but i'd like to see it show up in menuconfig
> >somehow.
 
> I respectfully disagree...  I think if these sort of FIXMEs show up in 
> menuconfig, you're not only cluttering up menuconfig, you also moving 
> past the level of programmer to the sysadmin/power-user level.  That 
> seems like it would generate more bug reports than useful work.
 
> About the only thing WRT menuconfig I would be ok with is commenting out 
> majorly broken drivers until they are fixed...

We have OBSOLETE, EXPERIMENTAL, why not BROKEN? 8)

It would appear as "BROKEN waiting for someone to fixme"

- Arnaldo

Re: Why can't Johnny compile?

[Arnaldo Carvalho de Melo]

Em Sat, Nov 16, 2002 at 07:37:32PM -0200, Arnaldo C. Melo escreveu:
> Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
> > About the only thing WRT menuconfig I would be ok with is commenting out 
> > majorly broken drivers until they are fixed...
> 
> We have OBSOLETE, EXPERIMENTAL, why not BROKEN? 8)
> 
> It would appear as "BROKEN waiting for someone to fixme"

If, like for EXPERIMENTAL, BROKEN is selected by the user, or better,
by a developer wanting to fix what is broken.

- Arnaldo

Re: Why can't Johnny compile?

[Alan Cox]

On Sat, 2002-11-16 at 21:42, Arnaldo Carvalho de Melo wrote:
> Em Sat, Nov 16, 2002 at 07:37:32PM -0200, Arnaldo C. Melo escreveu:
> > Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
> > > About the only thing WRT menuconfig I would be ok with is commenting out 
> > > majorly broken drivers until they are fixed...
> > 
> > We have OBSOLETE, EXPERIMENTAL, why not BROKEN? 8)
> > 
> > It would appear as "BROKEN waiting for someone to fixme"
> 
> If, like for EXPERIMENTAL, BROKEN is selected by the user, or better,
> by a developer wanting to fix what is broken.

Thats basically what "OBSOLETE" is

Re: Why can't Johnny compile?

[Dan Kegel]

Alan Cox wrote:
>>>Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
>>>
>>>>About the only thing WRT menuconfig I would be ok with is commenting out 
>>>>majorly broken drivers until they are fixed...
> 
> Thats basically what "OBSOLETE" is

So how 'bout this:

* mark all drivers that don't compile OBSOLETE.  That keeps us from
   trying to fix drivers without having hardware to test them.
   Anyone with proper hardware is invited to fix the drivers and then
   mark them non-OBSOLETE.
* make 'curyesconfig' and 'curmodconfig' compile everything that isn't OBSOLETE
* fix anything left over that keeps 'make curyesconfig'
   and 'make curmodconfig' from compiling
* maintainers try to not forward any patches to Linux that
   cause 'make curyesconfig' or 'make curmodconfig' not build
* OSDL does nightly 'curyesconfig' and 'curmodconfig builds from
   Linus's tree, and mails linux-kernel a link to the build log
   along with whether it succeeded or failed

That would give maintainers quick feedback about whether they'd
broken some obscure part of Linus's tree...

- Dan

Re: Why can't Johnny compile?

[romieu]

[Cc trimmed]

Dan Kegel <dank@kegel.com> :
[...]
> So how 'bout this:
> 
> * mark all drivers that don't compile OBSOLETE.  That keeps us from
>    trying to fix drivers without having hardware to test them.
>    Anyone with proper hardware is invited to fix the drivers and then
>    mark them non-OBSOLETE.

Plain old #warning doesn't work that bad and requires 0 extra new feature.

--
Ueimor

Re: Why can't Johnny compile?

[Patrick Finnegan]

On Sun, 17 Nov 2002 romieu@fr.zoreil.com wrote:

> [Cc trimmed]
>
> Dan Kegel <dank@kegel.com> :
> [...]
> > So how 'bout this:
> >
> > * mark all drivers that don't compile OBSOLETE.  That keeps us from
> >    trying to fix drivers without having hardware to test them.
> >    Anyone with proper hardware is invited to fix the drivers and then
> >    mark them non-OBSOLETE.
>
> Plain old #warning doesn't work that bad and requires 0 extra new feature.

I think there needs to be some sort of warning during the configuration
process - people will discover that a driver doesn't compile when they get
a screenfull of gcc errors and make halts compiling, they shouldn't need a
#warning to figure that out.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

Re: Why can't Johnny compile?

[Nathan]

On Sat, Nov 16, 2002 at 04:09:22PM -0800, Dan Kegel wrote:
> * maintainers try to not forward any patches to Linux that
>   cause 'make curyesconfig' or 'make curmodconfig' not build

The PLM is a *really* good way to get that verified for almost No Work.

> * OSDL does nightly 'curyesconfig' and 'curmodconfig builds from
>   Linus's tree, and mails linux-kernel a link to the build log
>   along with whether it succeeded or failed

Automatic emails to LK will become noise and get ignored very quickly.

> That would give maintainers quick feedback about whether they'd
> broken some obscure part of Linus's tree...

Maintainers of the major trees always get quick feedback.  In the form
of "it doesn't compile" and compile patches.  Inserting some proactive
testing into the development process would help more than the feedback.

It would be cool if maintainers would only accept patches that are
verified to compile.

The big problem compile errors causes with the pre* and rc* series
kernels is it vastly reduces the number of potential testers.  Not
because of an inability to apply patches, but because testing has to be
as easy as possible to get a wide audience.  Finding the "bug" of a
compile error is so common now, reporting the bug isn't even interesting
most of the time.  Testers know that chances are someone else has found
it and someone else is probably 75% done with the patch to fix it.

It would be a Good Thing if finding bugs in the kernel releases was
cause for at least a little bit of surprise and interest.

If any tree maintainers are interested in having their trees auto-sucked
into the PLM, please let me know.  I can set it up to email you the
compile results or not.

-Nathan

Re: Why can't Johnny compile?

[Alan Cox]

On Sun, 2002-11-17 at 00:09, Dan Kegel wrote:
> * mark all drivers that don't compile OBSOLETE.  That keeps us from
>    trying to fix drivers without having hardware to test them.
>    Anyone with proper hardware is invited to fix the drivers and then
>    mark them non-OBSOLETE.

On which platform with which combination of options, which compiler ?  

Right now its not worth doing, but as we get closer to a release it
becomes worth marking some stuff as obsolete - not however by random
"compile tests" but by careful thought

Re: Why can't Johnny compile?

[Bill Davidsen]

On Sat, 16 Nov 2002, Dan Kegel wrote:

> Alan Cox wrote:
> >>>Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
> >>>
> >>>>About the only thing WRT menuconfig I would be ok with is commenting out 
> >>>>majorly broken drivers until they are fixed...
> > 
> > Thats basically what "OBSOLETE" is
> 
> So how 'bout this:
> 
> * mark all drivers that don't compile OBSOLETE.  That keeps us from
>    trying to fix drivers without having hardware to test them.
>    Anyone with proper hardware is invited to fix the drivers and then
>    mark them non-OBSOLETE.

I would suggest that we not cause kconfig to attach a new, possibly
misleading, meaning to the terms OBSOLETE and BROKEN. Therefore I would
offer this nomenclature instead.

OBSOLETE - the code in question provides either support for a no longer
easily available hardware, or better software to support the hardware (or
feature) is available. It does not mean that the feature is known not to
work, just that there are alternatives.

BROKEN - the code in question is known not to work, may not compile. It
can be read as FIXME invitation.

Lots of people would immediately reject the idea of writing a driver from
scratch (including me, unless paid to do so), but at least some of those
who need working code might be willing to take the time to fix an existing
driver (or feature).

Two different concepts, and probably a good way to provide a quick "things
to do" list every time someone configures a kernel.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Why can't Johnny compile?

[Alan Cox]

> OBSOLETE - the code in question provides either support for a no longer
> easily available hardware, or better software to support the hardware (or
> feature) is available. It does not mean that the feature is known not to
> work, just that there are alternatives.

Currently (2.4) it means driver code which has not been updated to
current kernel APIs

Re: Why can't Johnny compile?

[Bill Davidsen]

On 18 Nov 2002, Alan Cox wrote:

> 
> > OBSOLETE - the code in question provides either support for a no longer
> > easily available hardware, or better software to support the hardware (or
> > feature) is available. It does not mean that the feature is known not to
> > work, just that there are alternatives.
> 
> Currently (2.4) it means driver code which has not been updated to
> current kernel APIs

If we add a BROKEN category, would you agree that it is a more accurate
description of the status? I'm not asking that this be back-ported to 2.4,
but I think of OBSOLETE describing the nec pre-symbios drivers or similar
things. Or the aha152x driver which I still can't get going in 2.5 :-(

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Why can't Johnny compile?

[Jeff Garzik]

Bill Davidsen wrote:

> If we add a BROKEN category, would you agree that it is a more accurate
> description of the status? I'm not asking that this be back-ported to 2.4,
> but I think of OBSOLETE describing the nec pre-symbios drivers or similar
> things. Or the aha152x driver which I still can't get going in 2.5 :-(
>

It's still early in the 2.5.x game to do this.

Re: Why can't Johnny compile?

[Alan Cox]

> things. Or the aha152x driver which I still can't get going in 2.5 :-(

152x seems to work

Re: Why can't Johnny compile?

[David G Hamblen]

On 19 Nov 2002, Alan Cox wrote:

> > things. Or the aha152x driver which I still can't get going in 2.5 :-(
>
> 152x seems to work
> -

I'm running 2.5.47-ac4, and it compiles with aha152x, but pcmcia doesn't
work:

# modprobe pcmcia_core
/lib/modules/2.5.47-ac4-apm/kernel/drivers/pcmcia/pcmcia_core.o:
unresolved symbol pcibios_read_config_dword
/lib/modules/2.5.47-ac4-apm/kernel/drivers/pcmcia/pcmcia_core.o: insmod
/lib/modules/2.5.47-ac4-apm/kernel/drivers/pcmcia/pcmcia_core.o failed
/lib/modules/2.5.47-ac4-apm/kernel/drivers/pcmcia/pcmcia_core.o: insmod
pcmcia_core failed



			Dave

Re: Why can't Johnny compile?

[Alan Cox]

On Tue, 2002-11-19 at 18:01, David G Hamblen wrote:
> On 19 Nov 2002, Alan Cox wrote:
> 
> > > things. Or the aha152x driver which I still can't get going in 2.5 :-(
> >
> > 152x seems to work
> > -
> 
> I'm running 2.5.47-ac4, and it compiles with aha152x, but pcmcia doesn't
> work:

Fixed in -ac6

Re: Why can't Johnny compile?

[Adam Kropelin]

On Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik wrote:
> john slee wrote:
> 
> >>If people want to get rivafb or an ancient ISA net driver building
> >>again... patches welcome.  But I don't think calls for the kernel to
> >
> >
> >yep, someone is maintaining ewrk3 again now :-), or at least i have seen
> >a couple of patches submitted
> 
> 
> hehe, yep, in fact there is an ewrk3 patch I still need to merge :)

Hehe, so my mailer *isn't* broken. And all along I've been trying to
figure out why mails to pobox.com aren't getting thru... ;)

BTW, I'd be willing to work on some other drivers if there are some
you'd like to see fixed. Probably won't have the hardware here to test
them but other listees can help out with that...

--Adam

Re: Why can't Johnny compile?

[Arnaldo Carvalho de Melo]

Em Fri, Nov 15, 2002 at 09:35:59PM -0800, Dan Kegel escreveu:
> john slee <indigoid@higherplane.net> wrote:
> >On Thu, Nov 14, 2002 at 10:58:09PM -0500, Patrick Finnegan wrote:
> >>It'd be nice if people simply tried compiling a patched kernel (all
> >>affected modules) before they submitted the patch, I'm betting you'd catch
> >>a lot of typos.  Also, compiling _everything_, even as a module, at
> >>least once before sumbitting the patch would probably help.

> >thats fine if there is an all-compiling kernel release out there.  right
> >now 2.5-bk is far from it.  last i checked allmodconfig (a couple of
> >days ago) there was major breakage all over llc, scsi, video, sound, ...
> >which kinda masks any breakages you might have introduced. 

> Hrmph.  Y'know, maybe it's time for us to collectively put our
> feet down, get 2.5-linus to the point where everything compiles,
> and keep it there.  After all, we are supposedly trying to
> *stabilize* 2.5.  It isn't stable if it doesn't compile...

mmkay, I'm working on the "missing symbols problems with llc in allmodconfig"
But cli/sti will take some more time, I think.

- Arnaldo

Re: Why can't Johnny compile?

[Nathan]

On Fri, Nov 15, 2002 at 09:35:59PM -0800, Dan Kegel wrote:
> Hrmph.  Y'know, maybe it's time for us to collectively put our
> feet down, get 2.5-linus to the point where everything compiles,
> and keep it there.  After all, we are supposedly trying to
> *stabilize* 2.5.  It isn't stable if it doesn't compile...

FYI, the OSDL has a "patch bot" system available that will do compile
verifications on patches.

Patches can be submitted against standard kernel releases or in a
depends-on fashion against other patches.

Six total compile configs are tried, UP & SMP of the following:

  - Default config
  - Desktop config (really just a bunch of stuff enabled)
  - STP config (required hardware support to run on the OSDL's STP)

When the tests are done running against your patch, you get a summary
email telling you which tests passed and which ones failed.

The system is at:  http://www.osdl.org/cgi-bin/plm

A sample page (kernel 2.5.47) is at:

  http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=943

Another sample (kernel 2.4.20-rc2) is at:

  http://www.osdl.org/cgi-bin/plm?module=patch_info&patch_id=978

Note the filters at the bottom, clicking on the FAIL by desktop config
gives the .config used in the test followed by enough of the tail of the
compile log to tell what went wrong.

Patches in the PLM can then be used in benchmark runs in the STP.

The standard 2.4 and 2.5 trees are auto-added after they hit our ftp
mirror.

I am interested in modifying the "Desktop" config to mirror the average
user as well as putting in a new "all" when we have the ability to do
it (/lots/ of modules...)  People having suggestions on what to include
in the Desktop config, please speak up.

People can also download the patch content from the patch info page.

Thanks,
Nathan