[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337198404.6724.81.camel@gandalf.stny.rr.com>
Date: Wed, 16 May 2012 16:00:04 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Ingo Molnar <mingo@...e.hu>,
Frederic Weisbecker <fweisbec@...il.com>,
David Sharp <dhsharp@...gle.com>,
Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] tracing: Remove useless 4 bytes of padding from
every event
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
--
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