john slee <[email protected]> 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
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
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
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
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
Em Fri, Nov 15, 2002 at 09:35:59PM -0800, Dan Kegel escreveu:
> john slee <[email protected]> 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
[email protected] (Jeff Garzik) wrote on 16.11.02 in <[email protected]>:
> 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:
> [email protected] (Jeff Garzik) wrote on 16.11.02 in <[email protected]>:
>
> > 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
> 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/
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
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
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
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
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
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
[Cc trimmed]
Dan Kegel <[email protected]> :
[...]
> 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
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
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
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
On Sun, 17 Nov 2002 [email protected] wrote:
> [Cc trimmed]
>
> Dan Kegel <[email protected]> :
> [...]
> > 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
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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> 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
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.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> things. Or the aha152x driver which I still can't get going in 2.5 :-(
152x seems to work
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
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