Why can't Johnny compile?
Quoted 10 lines · john slee
Quoted 4 lines · Patrick Finnegan
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
Quoted 10 lines · Dan Kegel
Quoted 3 lines · john slee
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
Quoted 5 lines · Jeff Garzik
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.
Quoted 9 lines
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
Quoted 5 lines · Patrick Finnegan
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
Quoted 4 lines · Jeff Garzik
Quoted 4 lines
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]
Quoted 5 lines · Patrick Finnegan
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
Quoted 5 lines · Patrick Finnegan
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
[email protected] (Jeff Garzik) wrote on 16.11.02 in <[email protected]>:
Quoted 4 lines
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
Em Sat, Nov 16, 2002 at 11:47:00AM +0200, Kai Henningsen escreveu:
Quoted 9 lines
[email protected] (Jeff Garzik) wrote on 16.11.02 in <[email protected]>:
Quoted 4 lines
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
Quoted 2 lines
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
Quoted 2 lines
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
Quoted 5 lines
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.
Signature · 1 line
toyota power: http://indigoid.net/
Em Fri, Nov 15, 2002 at 09:35:59PM -0800, Dan Kegel escreveu:
Quoted 12 lines
Quoted 10 lines · john slee
Quoted 4 lines · Patrick Finnegan
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.
Quoted 4 lines
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
Quoted 4 lines · Dan Kegel
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
Quoted 6 lines · john slee
Quoted 2 lines
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 :)
Quoted 6 lines
Quoted 2 lines
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...
Quoted 11 lines
Quoted 5 lines
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
Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
Quoted 5 lines
Quoted 3 lines · john slee
#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.
Quoted 7 lines
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
Em Sat, Nov 16, 2002 at 07:37:32PM -0200, Arnaldo C. Melo escreveu:
Quoted 7 lines
Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
Quoted 2 lines
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
Quoted 11 lines · Arnaldo Carvalho de Melo
Em Sat, Nov 16, 2002 at 07:37:32PM -0200, Arnaldo C. Melo escreveu:
Quoted 7 lines
Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
Quoted 2 lines
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
Quoted 5 lines · Alan Cox
Quoted 3 lines
Quoted 3 lines
Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
Quoted 1 line
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
[Cc trimmed]
Dan Kegel <[email protected]> :
[...]
Quoted 6 lines
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
Quoted 4 lines · On Sun, 17 Nov 2002 [email protected] wrote:
[Cc trimmed]
Dan Kegel <[email protected]> :
[...]
Quoted 8 lines
Quoted 6 lines
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
Quoted 4 lines · Dan Kegel
* 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
Quoted 2 lines · Dan Kegel
* 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.
Quoted 3 lines
* 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.
Quoted 2 lines
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
Quoted 6 lines · Dan Kegel
Quoted 5 lines · Alan Cox
Quoted 4 lines
Quoted 4 lines
Em Sat, Nov 16, 2002 at 04:04:05PM -0500, Jeff Garzik escreveu:
Quoted 2 lines
About the only thing WRT menuconfig I would be ok with is commenting out majorly broken drivers until they are fixed...
Quoted 8 lines
Quoted 1 line
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 5 lines
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
Quoted 8 lines · Alan Cox
Quoted 5 lines
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 :-(
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 5 lines · Bill Davidsen
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.
Quoted 1 line
things. Or the aha152x driver which I still can't get going in 2.5 :-(
152x seems to work
Quoted 4 lines · Alan Cox
Quoted 1 line
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
Quoted 9 lines · David G Hamblen
Quoted 4 lines · Alan Cox
Quoted 1 line
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
Quoted 11 lines · Jeff Garzik
Quoted 6 lines · john slee
Quoted 2 lines
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