linux-next: manual merge of the arm tree with Linus' tree

linux-next: manual merge of the arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Hi Russell,

Today's linux-next merge of the arm tree got a conflict in
kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
from the arm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched/core.c
index b342f57,ea13a09..0000000
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@@ -1932,6 -1932,8 +1932,7 @@@ static void finish_task_switch(struct r
  	local_irq_enable();
  #endif /* __ARCH_WANT_INTERRUPTS_ON_CTXSW */
  	finish_lock_switch(rq, prev);
+ 	finish_arch_post_lock_switch();
 -	trace_sched_stat_sleeptime(current, rq->clock);
  
  	fire_sched_in_preempt_notifiers(current);
  	if (mm)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Russell,
> 
> Today's linux-next merge of the arm tree got a conflict in
> kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> from the arm tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

This commit seems simple enough and has PeterZ's ack, but if 
there are more scheduler patches coming in this area then please 
send it to the scheduler tree first: we can create a pullable, 
stable topic branch for it which the ARM tree can then use.

That approach would also avoid conflicts as a side effect.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Russell,
> > 
> > Today's linux-next merge of the arm tree got a conflict in
> > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > from the arm tree.
> > 
> > Just context changes.  I fixed it up (see below) and can carry the fix as
> > necessary.
> 
> This commit seems simple enough and has PeterZ's ack, but if 
> there are more scheduler patches coming in this area then please 
> send it to the scheduler tree first: we can create a pullable, 
> stable topic branch for it which the ARM tree can then use.
> 
> That approach would also avoid conflicts as a side effect.

Please check your mailbox:

Date: Tue, 29 Nov 2011 12:22:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>,
        Russell King <linux@arm.linux.org.uk>
Subject: [RFC PATCH 1/6] sched: Introduce the finish_arch_post_lock_switch()
        scheduler hook

Date: Mon, 19 Dec 2011 14:57:48 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
        Peter Zijlstra <peterz@infradead.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Frank Rowand <frank.rowand@am.sony.com>
Subject: [RFC PATCH v2 1/6] sched: Introduce the finish_arch_post_lock_switch()
        scheduler hook

Date: Fri, 20 Jan 2012 17:42:27 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will.deacon@arm.com>,
        Frank Rowand <frank.rowand@am.sony.com>
Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
        scheduler hook

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi Russell,
> > > 
> > > Today's linux-next merge of the arm tree got a conflict in
> > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > from the arm tree.
> > > 
> > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > necessary.
> > 
> > This commit seems simple enough and has PeterZ's ack, but if 
> > there are more scheduler patches coming in this area then 
> > please send it to the scheduler tree first: we can create a 
> > pullable, stable topic branch for it which the ARM tree can 
> > then use.
> > 
> > That approach would also avoid conflicts as a side effect.
> 
> Please check your mailbox:

I'm aware of that old thread, I'd just prefer to hear about your 
plans patching the scheduler *before* you commit it to 
linux-next ;-)

Please make sure none of these scheduler patches go to the ARM 
tree without a proper Git space solution that involves the 
scheduler folks.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 09:36:30AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 07:16:22AM +0100, Ingo Molnar wrote:
> > > 
> > > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > > Hi Russell,
> > > > 
> > > > Today's linux-next merge of the arm tree got a conflict in
> > > > kernel/sched/core.c between commit 8c79a045fd59 ("sched/events: Revert
> > > > trace_sched_stat_sleeptime()") from Linus' tree and commit 1cf00341547a
> > > > ("sched: Introduce the finish_arch_post_lock_switch() scheduler hook")
> > > > from the arm tree.
> > > > 
> > > > Just context changes.  I fixed it up (see below) and can carry the fix as
> > > > necessary.
> > > 
> > > This commit seems simple enough and has PeterZ's ack, but if 
> > > there are more scheduler patches coming in this area then 
> > > please send it to the scheduler tree first: we can create a 
> > > pullable, stable topic branch for it which the ARM tree can 
> > > then use.
> > > 
> > > That approach would also avoid conflicts as a side effect.
> > 
> > Please check your mailbox:
> 
> I'm aware of that old thread, I'd just prefer to hear about your 
> plans patching the scheduler *before* you commit it to 
> linux-next ;-)
> 
> Please make sure none of these scheduler patches go to the ARM 
> tree without a proper Git space solution that involves the 
> scheduler folks.

Sorry, you're blaming the wrong person.  I got the commit via a pull,
not via a patch.

If that's how you want to run your bit of the kernel, then please be more
responsive when you're sent patches and say how you want to handle things.
Don't ignore patches and then blame people when conflicts happen.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> Sorry, you're blaming the wrong person.  I got the commit via 
> a pull, not via a patch.

This is the most idiotic excuse I've ever read.

Dammit, don't pull code you don't maintain and which you have 
not checked the background of, *especially* not if the 
originating discussion very clearly asked *you* to do it in 
another way.

We were modifying that very code in this development cycle, in 
the scheduler tree - a fact highlighted by the conflict - which 
you could have seen yourself, had you even attempted to 
test-merge your tree to linux-next ...

Let me quote PeterZ again:

> > Russell, what's the status of these patches? I'd like to see 
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some 
> > other patches on top.

Russell, read and reply to your mail in a timely and reliable 
fashion, that will avoid such mixups in the future.

> If that's how you want to run your bit of the kernel, then 
> please be more responsive when you're sent patches and say how 
> you want to handle things. Don't ignore patches and then blame 
> people when conflicts happen.

Stop blaming others for your own mistakes, one of the the 
scheduler maintainers replied to the patches a month ago, in an 
absolutely constructive fashion:

  http://lkml.org/lkml/2012/2/16/232

You never replied to PeterZ that I can see.

Again, fortunately it's not a big deal right now - both the 
commit and the conflict is trivial - but your current attitute 
towards applying patches and following discussions is rather sad 
and could cause bigger problems in the future.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Sorry, you're blaming the wrong person.  I got the commit via 
> > a pull, not via a patch.
> 
> This is the most idiotic excuse I've ever read.

Sod this crap, I'm dropping Catalin's patches.  Deal with the fucking thing
yourself.  Catalin, sorry, put some people are just total idiots over
simple merge conflicts and blow things totally out of proportion.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

[GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > Sorry, you're blaming the wrong person.  I got the commit via 
> > > a pull, not via a patch.
> > 
> > This is the most idiotic excuse I've ever read.
> 
> Sod this crap, I'm dropping Catalin's patches. [...]

As I said it in my first mail, doing that is unnecessary - but 
if you insist on being difficult then Catalin, feel free to pull 
the patch from tip:sched/arch:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch

   HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

it's v3.3-rc7 based so it will generate no conflict with 
linux-next. It only contains this commit so you can use it 
without pulling in other pending scheduler changes.

This is the trivial and easy Git based topic branch approach 
PeterZ asked Russell a month ago to consider:

   http://lkml.org/lkml/2012/2/16/232

which request Russell sadly ignored.

In any case, Catalin's ARM work is not blocked in any fashion.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> As I said it in my first mail, doing that is unnecessary - but 
> if you insist on being difficult then Catalin, feel free to pull 
> the patch from tip:sched/arch:

Nope, I'm not taking the tree anymore, you've refused to behave in a
reasonable way.  Your problem to sort out now.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> >
> > As I said it in my first mail, doing that is unnecessary - 
> > but if you insist on being difficult then Catalin, feel free 
> > to pull the patch from tip:sched/arch:
> 
> Nope, I'm not taking the tree anymore, [...]

So instead of saying "sure, lets avoid conflicts next time 
around" you are now *refusing* to take technically perfectly 
fine patches just because another maintainer asked you to use a 
different workflow for future patches? Wow ...

Regardless of the imperfect workflow I certainly find Catalin's 
work useful technically, so I'll send his preparatory commit to 
Linus in this merge window - I hope you will see sense later and 
won't block his subsequent ARM patches...

> [...] you've refused to behave in a reasonable way.  Your 
> problem to sort out now.

For the record, that's utter nonsense:

 - *You* failed to reply on the public thread to sort this out
   properly in the Git space, avoiding conflicts naturally:

      http://lkml.org/lkml/2012/2/16/232

   While generally we don't mind conflicts, I do mind 
   *avoidable* conflicts - and this was such a case.

 - *You* created a conflict by taking a tree that patched some 
   rather old version of the scheduler, shortly before the merge 
   window, when maintainer capacity is the shortest. PeterZ
   is a nice guy who will agree to just about any approach, but 
   I'm quite sure he did not tell you to do *that* ;-)

 - *You* replied to me in a rather dismissive and increasingly
   obnoxious style when I inquired about it constructively:

     http://lkml.org/lkml/2012/3/13/79

There were several easy solutions - I cannot believe that we are 
still arguing this:

 - it literally took me two minutes to create a proper Git
   solution, it's not rocket science. You could have done it, or
   I could have done it for you (as I have done it).

 - Or you could have replied to the public thread, explaining
   why that is not desirable.

 - Or you could have said "sure thing, lets do it that way next
   time around".

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > >
> > > As I said it in my first mail, doing that is unnecessary - 
> > > but if you insist on being difficult then Catalin, feel free 
> > > to pull the patch from tip:sched/arch:
> > 
> > Nope, I'm not taking the tree anymore, [...]
> 
> So instead of saying "sure, lets avoid conflicts next time 
> around" you are now *refusing* to take technically perfectly 
> fine patches just because another maintainer asked you to use a 
> different workflow for future patches? Wow ...

No, I'm pissed off at how you're treating me over this trivial issue,
so I'm taking the easy way out and getting out of the way.  If you want
to run your bit of the tree with idiotic rules about zero conflicts,
and "git solutions" then that's your perogative.  Just don't expect
other people to play with you.

The fact of the matter is that Peter Z. was fully aware of what was
happening.  He was aware that he'd been asked for his ack for that
patch (because I'd explicitly asked Peter for it, but not by email) -
and he provided his ack for that patch to Catalin:

http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html

Catalin sent a pull request to me, copying Peter Z on the 27th Feb:

http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html

I pulled it into my tree for testing, and pushed it out in the last
couple of days.

Moreover, these kinds of trivial conflicts are the type of things which
Linus wants to see between trees.  It allows him to get a feel for what's
going on, and makes Linus feel like he's more on top of things.  Linus
said that he would like to see these trivial conflicts (he said so to me
in an email dated 15th Jan 2011).

So please, stop your insistance on this zero conflict crap.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > As I said it in my first mail, doing that is unnecessary - 
> > > > but if you insist on being difficult then Catalin, feel free 
> > > > to pull the patch from tip:sched/arch:
> > > 
> > > Nope, I'm not taking the tree anymore, [...]
> > 
> > So instead of saying "sure, lets avoid conflicts next time 
> > around" you are now *refusing* to take technically perfectly 
> > fine patches just because another maintainer asked you to use a 
> > different workflow for future patches? Wow ...
> 
> No, I'm pissed off at how you're treating me over this trivial issue,
> so I'm taking the easy way out and getting out of the way.  If you want
> to run your bit of the tree with idiotic rules about zero conflicts,
> and "git solutions" then that's your perogative.  Just don't expect
> other people to play with you.
> 
> The fact of the matter is that Peter Z. was fully aware of what was
> happening.  He was aware that he'd been asked for his ack for that
> patch (because I'd explicitly asked Peter for it, but not by email) -
> and he provided his ack for that patch to Catalin:
> 
> http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
> 
> Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
> 
> http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
> 
> I pulled it into my tree for testing, and pushed it out in the last
> couple of days.
> 
> Moreover, these kinds of trivial conflicts are the type of things which
> Linus wants to see between trees.  It allows him to get a feel for what's
> going on, and makes Linus feel like he's more on top of things.  Linus
> said that he would like to see these trivial conflicts (he said so to me
> in an email dated 15th Jan 2011).
> 
> So please, stop your insistance on this zero conflict crap.

While I still think this is a storm in a teacup, I think you are 
subtly misunderstanding Linus's position about conflicts and you 
are seriously misrepresenting my request and my position as 
well:

The thing is, most conflicts are fine in general. So on one hand 
you are right, we *do* allow and quite often *keep* conflicts in 
place even within our own topic branches.

Those are *real* conflicts that Linus would arguably be 
interested in: two teams working on two things in parallel that 
somehow conflict at the code level content-wise or concept-wise 
- high level maintainers rightfully are curious about those 
kinds of conflicts because while often they are just fine, it 
might also be the canary of possible workflow problems or it 
might also be the canary of the code being shaped in some 
inefficient way.

On the other hand, this particular conflict you pushed to 
linux-next is *neither*, and this is what got my attention. This 
is a plain *STUPID* conflict.

Look into the fine conflict report Russell: it conflicts with 
*Linus's* tree, because it's based off some random 
barely-beyond-rc1 development window -rc3 base. Even at the 
commit date of Feb 27 we had a more stable base tree available - 
and especially when you pulled it, several weeks down the line, 
-rc3 was not a defensible base for the integrated result.

Having a patch applied to an old scheduler tree that is barely 
out of -rc1 and then pushing it out into linux-next at -rc8, 
without even checking how it integrates with upstream, barely a 
few days before the merge window is just plain stupid.

While nothing of what you talked to PeterZ is visible in the 
public record, I'm quite sure had you asked him about what base 
kernel to use, he'd have suggested something much more stable 
...

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > > 
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > 
> > > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > > >
> > > > > As I said it in my first mail, doing that is unnecessary - 
> > > > > but if you insist on being difficult then Catalin, feel free 
> > > > > to pull the patch from tip:sched/arch:
> > > > 
> > > > Nope, I'm not taking the tree anymore, [...]
> > > 
> > > So instead of saying "sure, lets avoid conflicts next time 
> > > around" you are now *refusing* to take technically perfectly 
> > > fine patches just because another maintainer asked you to use a 
> > > different workflow for future patches? Wow ...
> > 
> > No, I'm pissed off at how you're treating me over this trivial issue,
> > so I'm taking the easy way out and getting out of the way.  If you want
> > to run your bit of the tree with idiotic rules about zero conflicts,
> > and "git solutions" then that's your perogative.  Just don't expect
> > other people to play with you.
> > 
> > The fact of the matter is that Peter Z. was fully aware of what was
> > happening.  He was aware that he'd been asked for his ack for that
> > patch (because I'd explicitly asked Peter for it, but not by email) -
> > and he provided his ack for that patch to Catalin:
> > 
> > http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
> > 
> > Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
> > 
> > http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
> > 
> > I pulled it into my tree for testing, and pushed it out in the last
> > couple of days.
> > 
> > Moreover, these kinds of trivial conflicts are the type of things which
> > Linus wants to see between trees.  It allows him to get a feel for what's
> > going on, and makes Linus feel like he's more on top of things.  Linus
> > said that he would like to see these trivial conflicts (he said so to me
> > in an email dated 15th Jan 2011).
> > 
> > So please, stop your insistance on this zero conflict crap.
> 
> While I still think this is a storm in a teacup, I think you are 
> subtly misunderstanding Linus's position about conflicts and you 
> are seriously misrepresenting my request and my position as 
> well:
> 
> The thing is, most conflicts are fine in general. So on one hand 
> you are right, we *do* allow and quite often *keep* conflicts in 
> place even within our own topic branches.
> 
> Those are *real* conflicts that Linus would arguably be 
> interested in: two teams working on two things in parallel that 
> somehow conflict at the code level content-wise or concept-wise 
> - high level maintainers rightfully are curious about those 
> kinds of conflicts because while often they are just fine, it 
> might also be the canary of possible workflow problems or it 
> might also be the canary of the code being shaped in some 
> inefficient way.
> 
> On the other hand, this particular conflict you pushed to 
> linux-next is *neither*, and this is what got my attention. This 
> is a plain *STUPID* conflict.
> 
> Look into the fine conflict report Russell: it conflicts with 
> *Linus's* tree, because it's based off some random 
> barely-beyond-rc1 development window -rc3 base. Even at the 
> commit date of Feb 27 we had a more stable base tree available - 
> and especially when you pulled it, several weeks down the line, 
> -rc3 was not a defensible base for the integrated result.
> 
> Having a patch applied to an old scheduler tree that is barely 
> out of -rc1 and then pushing it out into linux-next at -rc8, 
> without even checking how it integrates with upstream, barely a 
> few days before the merge window is just plain stupid.
> 
> While nothing of what you talked to PeterZ is visible in the 
> public record, I'm quite sure had you asked him about what base 
> kernel to use, he'd have suggested something much more stable 
> ...

Why am _I_ responsible for which kernel version _Catalin_ used for _his_
patches when _he_ committed them?

You're insane.  Totally.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> Why am _I_ responsible for which kernel version _Catalin_ used 
> for _his_ patches when _he_ committed them?

If you then pull that tree from him and push it out to 
linux-next? Then *of course* you are responsible, it was your 
decision to pull it.

I frequently reject pulls from subsystem maintainers on similar 
(and sometimes lesser) grounds - because such mistakes tend to 
compound with time.

The thing is, if you do Git pulls from someone then you must be 
absolutely anal about it, because you cannot really fix things 
up after the fact. The people you pull from must be your 
extended arms, they must be doing an equal or better job than 
you. That gives a basis of trust.

Once that is established, you can be permissive about mistakes. 

But arguing that you are not responsible for what you pull is 
absolutely grotesque and establishes a new low for this 
discussion really...

Also, as I told you in the very first mail, I am *fine* with 
this having happened, so you having zapped the commits is 
indefensible IMO. Mistakes do happen and the patch is fine 
technically and sfr and Linus could have handled the trivial 
conflict. What I suggested was to do it a bit better in the 
future. Is that too much to ask for?

> You're insane.  Totally.

I think you owe me an apology :-(

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Why am _I_ responsible for which kernel version _Catalin_ used 
> > for _his_ patches when _he_ committed them?
> 
> If you then pull that tree from him and push it out to 
> linux-next? Then *of course* you are responsible, it was your 
> decision to pull it.
> 
> I frequently reject pulls from subsystem maintainers on similar 
> (and sometimes lesser) grounds - because such mistakes tend to 
> compound with time.
> 
> The thing is, if you do Git pulls from someone then you must be 
> absolutely anal about it, because you cannot really fix things 
> up after the fact. The people you pull from must be your 
> extended arms, they must be doing an equal or better job than 
> you. That gives a basis of trust.
> 
> Once that is established, you can be permissive about mistakes. 
> 
> But arguing that you are not responsible for what you pull is 
> absolutely grotesque and establishes a new low for this 
> discussion really...
> 
> Also, as I told you in the very first mail, I am *fine* with 
> this having happened, so you having zapped the commits is 
> indefensible IMO. Mistakes do happen and the patch is fine 
> technically and sfr and Linus could have handled the trivial 
> conflict. What I suggested was to do it a bit better in the 
> future. Is that too much to ask for?
> 
> > You're insane.  Totally.
> 
> I think you owe me an apology :-(

I owe you nothing.  From where I stand, I did nothing wrong.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > Why am _I_ responsible for which kernel version _Catalin_ used 
> > > for _his_ patches when _he_ committed them?
> > 
> > If you then pull that tree from him and push it out to 
> > linux-next? Then *of course* you are responsible, it was your 
> > decision to pull it.
> > 
> > I frequently reject pulls from subsystem maintainers on similar 
> > (and sometimes lesser) grounds - because such mistakes tend to 
> > compound with time.
> > 
> > The thing is, if you do Git pulls from someone then you must be 
> > absolutely anal about it, because you cannot really fix things 
> > up after the fact. The people you pull from must be your 
> > extended arms, they must be doing an equal or better job than 
> > you. That gives a basis of trust.
> > 
> > Once that is established, you can be permissive about mistakes. 
> > 
> > But arguing that you are not responsible for what you pull is 
> > absolutely grotesque and establishes a new low for this 
> > discussion really...
> > 
> > Also, as I told you in the very first mail, I am *fine* with 
> > this having happened, so you having zapped the commits is 
> > indefensible IMO. Mistakes do happen and the patch is fine 
> > technically and sfr and Linus could have handled the trivial 
> > conflict. What I suggested was to do it a bit better in the 
> > future. Is that too much to ask for?
> > 
> > > You're insane.  Totally.
> > 
> > I think you owe me an apology :-(
> 
> I owe you nothing.  From where I stand, I did nothing wrong.

Well, even ignoring the arguments you hurled several ad hominems 
at me while I wrote none.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> [...]
> 
> Having a patch applied to an old scheduler tree that is barely 
> out of -rc1 and then pushing it out into linux-next at -rc8, 
> without even checking how it integrates with upstream, barely 
> a few days before the merge window is just plain stupid.

So, while I cannot know what Linus will think and do once he 
gets such a conflict (my guess is that he'd just fix it up 
silently - it's really trivial), I can tell you what the 
conflict told *me*: that the communication channels between the 
ARM tree and the scheduler tree are not in the best of shape.

And that is what worried me enough to write a reply while 
recognizing that PeterZ acked the patch - not the triviality of 
the patch or the triviality of the conflict.

And dammit, I have the right and the duty to be concerned about 
a conflict in the scheduler code if I see it for the first time, 
not just Linus. Conflicts aren't magically just for Linus to be 
interested and act upon, they can occasionally be informative at 
subsystem maintainer levels just as well - like here...

What we should not do in terms of conflict avoidance are 
*excessive* cross-subsystem merges: for example you 
indiscriminately merging the totality of all pending scheduler 
changes into the ARM tree and thus forcing Linus's hand in terms 
of not being able to reject to pull the scheduler tree.

But if I got it right, working together on a trivial, 
well-isolated callback patch to make life easier is not frowned 
upon by Linus at all ...

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> Look into the fine conflict report Russell: it conflicts with 
> *Linus's* tree, because it's based off some random 
> barely-beyond-rc1 development window -rc3 base. Even at the 
> commit date of Feb 27 we had a more stable base tree available - 
> and especially when you pulled it, several weeks down the line, 
> -rc3 was not a defensible base for the integrated result.

I'm not going to ask someone to rebase their patches after they've been
fully tested on a set of platforms.  It has been stated many times that
rebasing invalidates the testing that the patches have been subjected
to, and these have been tested by several different people on a range
of platforms.

It seems what _you_ care more about is having nice clean git trees and
proper git flow at the detriment to dealing with tested changes.

The fact of the matter is that I took a set of well tested patches into
my tree which _you_ were copied on multiple times, that Peter Z. was
aware of what was happening, and which trivially conflict with some other
change which happened along the way.  Such a trivial conflict does _NOT_
justify rebasing the patch set, thereby invalidating all the testing that
has done.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > Look into the fine conflict report Russell: it conflicts with 
> > *Linus's* tree, because it's based off some random 
> > barely-beyond-rc1 development window -rc3 base. Even at the 
> > commit date of Feb 27 we had a more stable base tree available - 
> > and especially when you pulled it, several weeks down the line, 
> > -rc3 was not a defensible base for the integrated result.
> 
> I'm not going to ask someone to rebase their patches after 
> they've been fully tested on a set of platforms. [...]

That's a new argument which might be a valid concern in general 
*if you make that decision when you pull the tree* - but you 
should admit that you werent even aware of the conflict and of 
the root cause behind it, let alone be in the position to 
consider whether a rebase is justified in that case ...

( Paradoxially, rebasing is exactly what *you* ended up forcing
  others to do. I have not asked you or Catalin to rebase any
  existing commit. I merely asked about future plans. )

So I think you are just making this up on the fly. Really, if I 
push back on you in a 100% *permissive* fashion, and if my 
complaint is justified, then the proper response is for you to 
push back on your contributors - while we can keep all commits 
in place.

Instead you first pushed back on *me*, then you claimed that you 
are not responsible for what you pull, then you started zapping 
patches and claiming that you will never pull them again, 
blaming it all on me.

Again, a storm in a teacup IMO.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Russell King]

On Tue, Mar 13, 2012 at 01:44:33PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > > Look into the fine conflict report Russell: it conflicts with 
> > > *Linus's* tree, because it's based off some random 
> > > barely-beyond-rc1 development window -rc3 base. Even at the 
> > > commit date of Feb 27 we had a more stable base tree available - 
> > > and especially when you pulled it, several weeks down the line, 
> > > -rc3 was not a defensible base for the integrated result.
> > 
> > I'm not going to ask someone to rebase their patches after 
> > they've been fully tested on a set of platforms. [...]
> 
> That's a new argument which might be a valid concern in general 
> *if you make that decision when you pull the tree* - but you 
> should admit that you werent even aware of the conflict and of 
> the root cause behind it, let alone be in the position to 
> consider whether a rebase is justified in that case ...

No Ingo.  I was aware of the conflict, because when I merged it into
my test tree, I got that conflict and fixed it up myself before I
tested the frigging thing.

> So I think you are just making this up on the fly.

If you think that, we have nothing further to discuss.  But I know
I'm right, because:

commit e3507976ee7ad0a58fa68ce919a7acfcfec28e3b
Merge: 4c17fe7 8cee1aa
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Thu Mar 8 09:51:31 2012 +0000

    Merge branch 'intr-ctxsw' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux

    Conflicts:
        kernel/sched/core.c

http://ftp.arm.linux.org.uk/git/?p=linux-next.git;a=commitdiff;h=e350797
(which is _not_ in a public branch, and is _only_ accessible via knowing
the commit id.)

Oh look, March 8th.  Oh, that's last Thursday.  Oh, maybe I did merge
it a while back after all, maybe I'm not making this crap up.  Maybe
I did know about the conflict but didn't think anything of it because
it was soo trivial.

> Instead you first pushed back on *me*, then you claimed that you 
> are not responsible for what you pull, then you started zapping 

No I did not.  What I said was that I'm not responsible for the points
at which people choose to base their patches, which is something entirely
different.  Unlike you, I have _no_ _problem_ with pulling work based on
_any_ -rc, or indeed any commit whatsoever - provided it's been tested
and it merges relatively cleanly with the branch I'm pulling it into.

> patches and claiming that you will never pull them again, 
> blaming it all on me.

I'm only blaming this thread on you, precisely because you're making a
mountain out of a mole hill.  There's no problem here.  Really.  At all.
You're just blowing it out of all proportion making it into some huge big
issue.  _That_ alone is the whole reason why I've dropped Catalins patches.
I don't want to be subjected to your rants over this.  Instead, _you_ can
deal with this patch set and deal with the other conflicts which git can
resolve automatically.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> > Instead you first pushed back on *me*, then you claimed that 
> > you are not responsible for what you pull, then you started 
> > zapping
> 
> No I did not.  What I said was that I'm not responsible for 
> the points at which people choose to base their patches, which 
> is something entirely different. [...]

What are you talking about?

Firstly, in general *every single bit* of what you pull, 
including the base, the patch titles, the commit logs, the 
signoff chain, etc. is all part of the picture and you 
absolutely should require your contributors and submaintainers 
to do a fine job with all that.

No ifs and whens about that - it all becomes your responsibility 
as well when you decide to pull from people.

Instead you are now teaching them the exact *opposite*: for 
example you have just declared that you don't feel responsible 
for the base kernel ...

Using a sane base is IMHO part of Git pull 101. Teaching 
contributors or submaintainers to not use too old base kernels 
(or too new ones, for example during the merge window) is an 
important part of the picture.

A basic rule for bases is to either use the previous stable 
kernel release, of if that's not possible then use the freshest 
-rc available at the time of the commit - which by my quick look 
should have been about -rc6, not -rc3.

Secondly, my other problem was that this all surfaced today, at 
-rc8 time, shortly before the merge window, a very busy period 
of time.

If this was committed a month ago, if you indeed saw the 
conflict earlier proves *more* workflow breakage IMO: you pushed 
it upstream despite being aware of it being the result of a 
slightly suboptimal base, without asking whether the scheduler 
folks are still fine with all that?

Thirdly, all this totally ignores the issue you still have not 
answered: why did you leave PeterZ public lkml question about 
this unanswered:

   http://lkml.org/lkml/2012/2/16/232

PeterZ's request to put this into a separate branch was totally 
reasonable IMHO - and could have avoided this long thread, 
amongst other things. Instead you've mixed it with other bits.

Really, my quick impression is that you should learn to push 
back downstream a bit, especially as I didn't even ask for a 
rebase, a revert or anything other drastic.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

Anyway - regardless of any differences and flames about workflow 
details, both you and Catalin should still feel free to use both 
the original commit (1cf00341547a) or the tip:sched/arch branch 
I provided (01f23e1630d9).

[ At the end of the merge window I'll try to make sure that at 
  least one of them got upstream ;-) ]

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Catalin Marinas]

Hi Ingo,

On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> Anyway - regardless of any differences and flames about workflow 
> details, both you and Catalin should still feel free to use both 
> the original commit (1cf00341547a) or the tip:sched/arch branch 
> I provided (01f23e1630d9).

About the scheduler hook patch, would it go into mainline via the
sched/urgent or the sched/arch branch? I would like to rebase the
ARM-specific patches on top of one of these branches and send you a pull
request (with Russell's ack).

Alternatively, I can wait until some 3.4-rc (and merge the ARM patches
via Russell).

Thanks.

-- 
Catalin

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Ingo Molnar]

* Catalin Marinas <catalin.marinas@arm.com> wrote:

> Hi Ingo,
> 
> On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> > Anyway - regardless of any differences and flames about workflow 
> > details, both you and Catalin should still feel free to use both 
> > the original commit (1cf00341547a) or the tip:sched/arch branch 
> > I provided (01f23e1630d9).
> 
> About the scheduler hook patch, would it go into mainline via 
> the sched/urgent or the sched/arch branch? I would like to 
> rebase the ARM-specific patches on top of one of these 
> branches and send you a pull request (with Russell's ack).

I've merged it into sched/urgent yesterday, which I'll send to 
Linus - so you can base it on that.

Thanks,

	Ingo

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Catalin Marinas]

On Fri, Mar 30, 2012 at 03:25:44PM +0100, Ingo Molnar wrote:
> 
> * Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> > Hi Ingo,
> > 
> > On Tue, Mar 13, 2012 at 03:47:16PM +0000, Ingo Molnar wrote:
> > > Anyway - regardless of any differences and flames about workflow 
> > > details, both you and Catalin should still feel free to use both 
> > > the original commit (1cf00341547a) or the tip:sched/arch branch 
> > > I provided (01f23e1630d9).
> > 
> > About the scheduler hook patch, would it go into mainline via 
> > the sched/urgent or the sched/arch branch? I would like to 
> > rebase the ARM-specific patches on top of one of these 
> > branches and send you a pull request (with Russell's ack).
> 
> I've merged it into sched/urgent yesterday, which I'll send to 
> Linus - so you can base it on that.

Thanks.

Russell, are you happy for me to add your acked-by to the ARM patches?

-- 
Catalin

Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback

[Catalin Marinas]

Hi Ingo,

On Tue, Mar 13, 2012 at 09:26:49AM +0000, Ingo Molnar wrote:
> As I said it in my first mail, doing that is unnecessary - but 
> if you insist on being difficult then Catalin, feel free to pull 
> the patch from tip:sched/arch:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch
> 
>    HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
> 
> it's v3.3-rc7 based so it will generate no conflict with 
> linux-next. It only contains this commit so you can use it 
> without pulling in other pending scheduler changes.

Thanks for merging the scheduler hook.

So I'll send Russell another pull request after the 3.4-rc1, containing
only ARM patches. The only drawback is that the removal of
__ARCH_WANT_INTERRUPTS_ON_CTXSW will have to wait another release cycle.

-- 
Catalin

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> Please check your mailbox:
> 
> Date: Fri, 20 Jan 2012 17:42:27 +0000
> From: Catalin Marinas <catalin.marinas@arm.com>
> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
>         Peter Zijlstra <peterz@infradead.org>,
>         Will Deacon <will.deacon@arm.com>,
>         Frank Rowand <frank.rowand@am.sony.com>
> Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
>         scheduler hook

Btw., are you losing emails? Because the reply from peterz to 
those patches, a month ago, was pretty clear:

> > Russell, what's the status of these patches? I'd like to see 
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some 
> > other patches on top.

You never replied to PeterZ's request, you just ignored this 
scheduler maintainer request and you just did it in some random 
way that was most convenient to you many weeks after the thread 
died down, ignoring everyone else's concerns - a pretty usual 
pattern from you I have to say.

Had you followed PeterZ's request this conflict in linux-next 
could have been avoided, amongst other things.

Given that the merge window is close I doubt there will be 
other, more difficult to resolve conflicts, but this incident 
again demonstrates your inability to communicate efficiently and 
amicably, forcing me to highlight it in this trivial case 
because it's a sadly reoccuring pattern.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > Please check your mailbox:
> > 
> > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> >         Peter Zijlstra <peterz@infradead.org>,
> >         Will Deacon <will.deacon@arm.com>,
> >         Frank Rowand <frank.rowand@am.sony.com>
> > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> >         scheduler hook
> 
> Btw., are you losing emails? Because the reply from peterz to 
> those patches, a month ago, was pretty clear:
> 
> > > Russell, what's the status of these patches? I'd like to see 
> > > them land in 3.4 if possible. I'm fine either way, I'll
> > >
> > > probably ask Ingo to pull your tree so that I can stack some 
> > > other patches on top.
> 
> You never replied to PeterZ's request, you just ignored this 
> scheduler maintainer request and you just did it in some random 
> way that was most convenient to you many weeks after the thread 
> died down, ignoring everyone else's concerns - a pretty usual 
> pattern from you I have to say.

Sigh.  You know, people communicate via other methods from time to time.
How the hell do you think PeterZ provided his ack for the patch?

Stop looking for people to blame.  Instead, if you failed to communicate
about how you wanted to handle the patch, blame yourself instead.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Ingo Molnar]

* Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> > 
> > > Please check your mailbox:
> > > 
> > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > >         Peter Zijlstra <peterz@infradead.org>,
> > >         Will Deacon <will.deacon@arm.com>,
> > >         Frank Rowand <frank.rowand@am.sony.com>
> > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > >         scheduler hook
> > 
> > Btw., are you losing emails? Because the reply from peterz to 
> > those patches, a month ago, was pretty clear:
> > 
> > > > Russell, what's the status of these patches? I'd like to see 
> > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > >
> > > > probably ask Ingo to pull your tree so that I can stack some 
> > > > other patches on top.
> > 
> > You never replied to PeterZ's request, you just ignored this 
> > scheduler maintainer request and you just did it in some 
> > random way that was most convenient to you many weeks after 
> > the thread died down, ignoring everyone else's concerns - a 
> > pretty usual pattern from you I have to say.
> 
> Sigh.  You know, people communicate via other methods from 
> time to time. How the hell do you think PeterZ provided his 
> ack for the patch?

He provided it via email to lkml:

  http://lkml.org/lkml/2012/2/27/210

But he asked *you* to do a proper Git space solution:

  http://lkml.org/lkml/2012/2/16/232

You *never* replied to that request that I can see, you just 
ignored it, why?

This discussion shows that you seem to have basic reading 
comprehension problems.

Thanks,

	Ingo

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

From: Catalin Marinas <catalin.marinas@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
        Peter Zijlstra <peterz@infradead.org>
Subject: [GIT PULL] ARM: Remove the __ARCH_WANT_INTERRUPTS_ON_CTXSW
        definition
Delivery-date: Mon, 27 Feb 2012 16:45:17 +0000

Hi Russell,

Could you please pull the context switching patches for ARM, together
with a generic hook acked by PeterZ?

Thanks,

On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > > 
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > 
> > > > Please check your mailbox:
> > > > 
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > >         Peter Zijlstra <peterz@infradead.org>,
> > > >         Will Deacon <will.deacon@arm.com>,
> > > >         Frank Rowand <frank.rowand@am.sony.com>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > >         scheduler hook
> > > 
> > > Btw., are you losing emails? Because the reply from peterz to 
> > > those patches, a month ago, was pretty clear:
> > > 
> > > > > Russell, what's the status of these patches? I'd like to see 
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some 
> > > > > other patches on top.
> > > 
> > > You never replied to PeterZ's request, you just ignored this 
> > > scheduler maintainer request and you just did it in some 
> > > random way that was most convenient to you many weeks after 
> > > the thread died down, ignoring everyone else's concerns - a 
> > > pretty usual pattern from you I have to say.
> > 
> > Sigh.  You know, people communicate via other methods from 
> > time to time. How the hell do you think PeterZ provided his 
> > ack for the patch?
> 
> He provided it via email to lkml:
> 
>   http://lkml.org/lkml/2012/2/27/210
> 
> But he asked *you* to do a proper Git space solution:
> 
>   http://lkml.org/lkml/2012/2/16/232
> 
> You *never* replied to that request that I can see, you just 
> ignored it, why?

I talked to peterz by other means.  He gave his ack after that message was
sent.  He was fully aware of what was happening.

> This discussion shows that you seem to have basic reading 
> comprehension problems.

And your a fucking idiot too.  Go to hell Ingo and stop being an utter
prat.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm tree with Linus' tree

[Russell King]

Oh and one last thing.  I'm never going to take any patch which touches
the scheduler ever again, no matter how trivial.  If that means people
can't get their patches in, then that's not my loss - that's your loss.
Especially when they're removing a special case from the scheduler -
which I hasten to add was requested by PeterZ.

I really don't care what you have to say in reply, I'm no longer listening
to objectionable people like you who make a mountain out of a mole hill.

On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > > 
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > 
> > > > Please check your mailbox:
> > > > 
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > >         Peter Zijlstra <peterz@infradead.org>,
> > > >         Will Deacon <will.deacon@arm.com>,
> > > >         Frank Rowand <frank.rowand@am.sony.com>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > >         scheduler hook
> > > 
> > > Btw., are you losing emails? Because the reply from peterz to 
> > > those patches, a month ago, was pretty clear:
> > > 
> > > > > Russell, what's the status of these patches? I'd like to see 
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some 
> > > > > other patches on top.
> > > 
> > > You never replied to PeterZ's request, you just ignored this 
> > > scheduler maintainer request and you just did it in some 
> > > random way that was most convenient to you many weeks after 
> > > the thread died down, ignoring everyone else's concerns - a 
> > > pretty usual pattern from you I have to say.
> > 
> > Sigh.  You know, people communicate via other methods from 
> > time to time. How the hell do you think PeterZ provided his 
> > ack for the patch?
> 
> He provided it via email to lkml:
> 
>   http://lkml.org/lkml/2012/2/27/210
> 
> But he asked *you* to do a proper Git space solution:
> 
>   http://lkml.org/lkml/2012/2/16/232
> 
> You *never* replied to that request that I can see, you just 
> ignored it, why?
> 
> This discussion shows that you seem to have basic reading 
> comprehension problems.
> 
> Thanks,
> 
> 	Ingo

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: