[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110802220619.GI27083@one.firstfloor.org>
Date: Wed, 3 Aug 2011 00:06:19 +0200
From: Andi Kleen <andi@...stfloor.org>
To: David Rientjes <rientjes@...gle.com>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: Revert needed: udev spewing warnons on common systems in 3.0
> All of the examples that I've cited that were fixed as a result of the
> printk_once() were through bugzilla for the developers of those
> applications, I didn't talk to any distro when I publically said I would
> handle all reports of this warning that people didn't know how to triage.
The distros would have updated udev at some point anyways.
But they won't do it for old releases.
But the users who don't want to update will just be annoyed
(in Linus words) the backtrace forever.
The big problem I have with your "use kernel WARN_ONs to social engineer"
approach is that the devalues a good mechanism to report kernel
problems.
Traditionally at least I looked at all backtraces
and tried to get at the bottom of the problem to improve the kernel.
I know from email that users reported those too.
Now that all my test systems spew them on every boot I cannot do
that anymore. When I see a backtrace scrolling by I now just
think "Ah it's probably David Rientjes trying to social engineer
someone again".
And then some point noone will look at backtraces anymore because
they have become normal. Really serious problems will get missed.
And this is a bad thing.
IMHO still the only sensible thing that can be done with this patch
is to revert it.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists