* Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Wednesday, 8 of October 2008, David Miller wrote: > > From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> > > Date: Tue, 7 Oct 2008 23:58:33 +0100 > > > > > > This should have been fixed by: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f5a6d958b5d0a10e7e7a9dee1862fb31d08c6d26 > > > > > > You mean - hidden by - that change should IMHO be reverted > > > > Grrr... I totally agree. > > Even though they are false positives in many cases? > > (Yes, they are). it's your judgement call i guess - i just wanted to challenge the terminology of calling it a fix ;-) Can you think of any good way of reintroducing the good aspect of the WARN(), without the false positives? [ If not, and if the WARN()s do more harm than good then it's the right change. ] But generally the trend is the opposite direction: we try to add as many WARN()s as possible, and we need even more good WARN()s in the kernel. When we meet false positives we try to improve the quality/yield of the warning, not eliminate it. Granted, they are a bit embarrassing when they show up in the top 10 but they are also very helpful and are tracked very nicely and lead to actual bugfixes that _matter_. Kerneloops.org is a wonderful tool: it enables a broad spectrum of users to help us out with their feedback, without them being forced into any manual work, and without them having to understand the kernel bug reporting workflow. Its scale is already enormous: 3000+ bugs reported per week. (many kudos Arjan!) Once its growth stabilizes (all the large distros have it either enabled today or have the client in their pipeline) we can even observe long-term trends and estimate release-to-release suckiness. That was impossible before and maintainers were left largely to imprecise intuitive guesses about where we stand wrt. kernel quality. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
