[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1208150116570.32033@ionos>
Date: Wed, 15 Aug 2012 01:33:09 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Tejun Heo <tj@...nel.org>
cc: LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
mingo@...hat.com, Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCHSET] timer: clean up initializers and implement irqsafe
timers
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Wed, Aug 15, 2012 at 12:45:24AM +0200, Thomas Gleixner wrote:
> > And we have very well worked out mechanisms regarding cross tree
> > changes, i.e. providing minimal trees to pull for other maintainers.
>
> If you look at the review branches, they're actually structured that
> way so that the timer part can be pulled separately. If the
> maintainer wants to do that, sure. If the maintainer thinks routing
> through another tree is fine, that's okay too. Subsystem boundaries
> are all good and great but it's not some absolute barrier which can't
> be crossed at any cost.
That's not about any cost. You are trying to force stuff into -next
with a THREE workdays notice, just because you think that your stuff
is so important.
Have you ever tried to understand how the kernel development system
works?
> I probably should have written "if the maintainer doesn't object, I
> think it would be easier to route these through wq/for-3.7 as it will
> be the only user for now, blah blah blah" instead and maybe I
> misjudged the character of the changes or the subsystem. That said, I
> think you're inferring too much.
No, I'm, not inferrring too much. It's not about what you should have
written.
It's about your general attitude. You really think that I accept all
that stuff just because you add some "blah, blah, blah" to some mail?
Far from it!
To convince me to accept your patches you should start answering my
questions and suggestions seriously in the first place and not
discarding them upfront as lunatic visions.
As long as you can't provide a proper counter argument against
maintaining the timer in the same context as the work, no matter what
the underlying mechanism to achieve this will be, I'm not going to
accept any of this hackery neither near next nor mainline.
Thanks,
tglx
--
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