public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: David Rientjes <rientjes@google.com>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org
Subject: Re: Revert needed: udev spewing warnons on common systems in 3.0
Date: Mon, 01 Aug 2011 23:07:55 -0700	[thread overview]
Message-ID: <m2pqko1h38.fsf@firstfloor.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1108011928530.15596@chino.kir.corp.google.com> (David Rientjes's message of "Mon, 1 Aug 2011 19:34:40 -0700 (PDT)")

David Rientjes <rientjes@google.com> writes:

>
>> Also the warning is completely useless: noone will be "fixing"
>> udev on old distributions.
>> 
>
> udev was fixed for v162, but admittedly that won't help on old 

Nobody wants to update udev if they can avoid it, especially not for
such an extremly obscure reason.

Repeat after me: Linux is not supposed to break old user land.

And not breaking in this case includes not randomly spewing useless
backtraces.

If you feel the need to social engineer the Chromium people, please
do it by email, not by keeping other people's  kernel logs hostage.

> distributions.  The WARN_ONCE() was intended to be in place for a year 
> just like its previous form, printk_once(), and then the tunable will 
> disappear and result in no error message.

printk_once() is fine, but oopsy looking backtraces are not.

>> IMHO that's not acceptable to break common user land like this.
>> Linux is supposed to be binary compatible and this patch is not
>> in this spirit.
>> 
>
> Can you show additional breakage that still need to be fixed in userspace 
> applications (we can't do anything about old distributions, it'll be a 
> silent failure in a year's time)? 

Simply backtraces are not supposed to happen unless something 
is really broken. That's not the case here. The old distribution
works perfectly fine and will continue to do so.

> udev was fixed for v162, kde was fixed 
> for 4.6.1

... and users will continue to run old versions.


> So I'm certainly not changing an interface and leaving people to fix it 
> up, I've been actively involved in doing so for the known userspace that 
> does touch the tunable.  I think it's better for users to be notified 
> whether by "scary" warnings in the log (come on, we should be able to warn 
> about deprecated interfaces in a log without mass failures) as some

You can warn, but not using oopsy looking backtraces. That trigger
all the bug reporting machinery. That is just  annoying.

> diligence before removing the tunable. 

It's not due diligence, it's total overkill for this.

I still think reverting this patch is the right thing to do.

Otherwise I have to do it in my local trees :-/ (it's certainly preferable
than messing with udev)

-Andi


-- 
ak@linux.intel.com -- Speaking for myself only

  reply	other threads:[~2011-08-02  6:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02  0:52 Revert needed: udev spewing warnons on common systems in 3.0 Andi Kleen
2011-08-02  1:32 ` Andrew Morton
2011-08-02  1:41   ` Linus Torvalds
2011-08-02  2:22     ` David Rientjes
2011-08-02  9:16       ` Alan Cox
2011-08-02  9:53         ` David Rientjes
2011-08-02 10:11           ` Alan Cox
2011-08-02 11:22             ` David Miller
2011-08-02 14:45             ` Andi Kleen
2011-08-02 21:50               ` David Rientjes
2011-08-02 21:45             ` David Rientjes
2011-08-02 22:06               ` Andi Kleen
2011-08-02 11:20           ` David Miller
2011-08-02  2:34 ` David Rientjes
2011-08-02  6:07   ` Andi Kleen [this message]
2011-08-02  9:54     ` [patch] oom: change warning for deprecated oom_adj to avoid WARN_ONCE() David Rientjes
2011-08-03  6:10       ` Borislav Petkov
2011-08-04  6:04         ` David Rientjes
2011-08-04  7:48           ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2pqko1h38.fsf@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox