From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
David Sharp <dhsharp@google.com>,
Vaibhav Nagarnaik <vnagarnaik@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH] tracing: Remove useless 4 bytes of padding from every event
Date: Wed, 16 May 2012 16:00:04 -0400 [thread overview]
Message-ID: <1337198404.6724.81.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <CA+55aFzVngkixn-t0mK8QqgnPhCzN2AsUtzfZ3BkLiJAcjNOzQ@mail.gmail.com>
On Wed, 2012-05-16 at 12:33 -0700, Linus Torvalds wrote:
> F16 and F17 seem to have powertop-1.98, which I assume is the new
> world order already. But maybe I assume incorrectly.
Seriously though. What's your take on changing the kernel that will
break an older distro. Obviously, this change is too early to apply. But
because an old distro has one app that will break if we make a change in
the kernel, is that enough to keep that change out?
Lets say we are at F23, and F18+ have the new powertop tools. Lets even
go to say that F16 and F17 have updated their powertop to powertop v2.
Because someone may be running a F17 without updates, which has powertop
that will break if they update their kernel, rational to keeping that
change out?
I want to know if this change will ever go in. Otherwise, I have to make
workarounds for it. I have no problem with that, as I will be adding
workarounds anyway, but this will continue to punish the tools that use
the non-workaround methods even though they don't break with the change.
Now if you say that it's OK to break and old distro if the affected
tools in the new distros work. What's the timeframe of that? One year?
-- Steve
next prev parent reply other threads:[~2012-05-16 20:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 13:44 Steven Rostedt
2012-05-16 17:24 ` [RFC][PATCH v2] " Steven Rostedt
2012-05-16 19:33 ` [RFC][PATCH] " Linus Torvalds
2012-05-16 19:36 ` Arjan van de Ven
2012-05-16 19:47 ` Steven Rostedt
2012-05-16 19:51 ` Linus Torvalds
2012-05-16 20:03 ` Steven Rostedt
2012-05-17 8:04 ` Ingo Molnar
2012-05-16 20:00 ` Steven Rostedt [this message]
2012-05-16 20:04 ` Linus Torvalds
2012-05-16 20:07 ` Arjan van de Ven
2012-05-16 20:13 ` Steven Rostedt
2012-05-16 20:14 ` Dave Jones
2012-05-16 20:16 ` Arjan van de Ven
2012-05-17 8:06 ` Ingo Molnar
2012-05-17 12:11 ` Steven Rostedt
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=1337198404.6724.81.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=dhsharp@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=vnagarnaik@google.com \
/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
all inboxes | Powered by JetHome®