Message-Id: <1222989842.2995.240.camel@laptop-eth>
Date:	Thu, 02 Oct 2008 16:24:02 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Veen <arjan@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jon Masters <jonathan@...masters.org>,
	Sven Dietrich <sdietrich@...e.de>
Subject: Re: [RFC patch 0/5] genirq: add infrastructure for threaded
	interrupt handlers

On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
> 
> On Thu, 2 Oct 2008, Daniel Walker wrote:
> 
> > On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
> > 
> > > Why are you bringing up real time in this thread?? The thread has
> > > absolutely nothing to do with real time. This thread is about a better
> > > way to handle interrupt handlers.
> > 
> > I'm concerned about the connection between the two, which is what I'm
> > commenting on.
> 
> Well, please take that up separately. Do you see these patches going
> into the -rt tree?  No, they are going in mainline. We will deal with
> them for -rt when the time comes.

It's an RFC after all, it's not going into anything at this point..

> > 
> > > > 
> > > > I also don't see a clear connection between these changes and ultimately
> > > > removing spinlock level latency in the kernel. I realize you don't
> > > > address that in your comments, but this is part of the initiative to
> > > > remove spinlock level latency..
> > > 
> > > Again, this thread has nothing to do with removing spinlock level latency.
> > > The reason Thomas did not address this is because it is OFF TOPIC!!!!
> > 
> > If they are connected (which I think we established) , then it's not out
> > of line for me to discuss the direction of these changes as related to
> > other components of real time.
> 
> You are bringing up concerns about mainline changes with something that
> is maintained outside the mainline tree.  Changes to mainline have never
> been influenced by changes maintained outside of mainline.

Again it's an RFC .. It's not going into mainline.. 

> > 
> > > > 
> > > > So with this set of changes and in terms of real time, I'm wonder your
> > > > going with this ?
> > > 
> > > You brought in this relationship with real time, just because real time 
> > > uses threaded interrupts. This thread has nothing to do with real time. 
> > > That is what Ingo, Thomas and myself are trying to ge through to you.
> > 
> > You know Steven, often times you start a conversation and you have no
> > idea where it will end up.. You can't always control which direction it
> > will go..
> 
> Yes Daniel, I know. But this is not a conversation. This is a email thread
> that is talking about changes to mainline. The mainline kernel developers
> really don't care about any issues that these changes will do to the
> real time project. The real time project is a niche, and is currently
> outside the mainline tree. Hence, lets stop bothering mainline 
> developers with our issues.

Your speaking for a lot of developers.. It's an RFC, it's coming from
real time developers, it's real time connected, and this is the real
time development list ..

Your preempt-rt patch isn't even what I'm commenting on.

> > 
> > > The strong reaction from Thomas is that you just brought up something that 
> > > is completely off topic.
> > 
> > We already debated this fact Steven. real time and this type of
> > threading are connected. It's not off topic to discuss connected
> > components.
> 
> No Daniel, it is off topic.  The thread is not about real time issues.
> This thread is about mainline. If you have an issue that these changes
> will make to the current mainline tree, then please, by all means, bring
> them up. But do not bring up issues that only affect outside of mainline.

The issues I've brought up are specifically design comments/concerns
related to future directions.. I was not at all speaking to your real
time changes..

> > 
> > If the intent here is to totally disconnect these threading patches from
> > any type of real time in the future, then that's a good answer to my
> > original question .. That these changes have no future what so ever in
> > regards to real time.
> 
> No the intent here is to handle mainline issues. The real time issues you
> consistantly bring up are not important to most kernel developers. If
> you have real time issues with this change, bring that up on a real 
> time forum. Not in this thread.  The changes in this thread are dealing
> with mainline interrupt handlers. There have been several kernel device 
> driver writers who asked us to get interrupt threads in mainline. This was 
> not about real time, this was about helping out mainline kernel 
> developers.

Real time forum ? That's what this list is .. If you want this thread to
stop , you should stop responding to my comments .. Really Steven ..

> > 
> > If they will be used in the future for real time then we should discuss
> > it. I don't think that's off topic at all.
> > 
> > > Basically, drop the real time topic from this thread. It's not related. 
> > > Yes real time addresses threaded interrupts, but just because we are 
> > > talking about threaded interrupts does not mean we are talking about real 
> > > time.
> > 
> > I don't see why you are so concerned with this.. Real time is taboo now?
> 
> Not at all, Daniel, but this thread is not the appropriate place to 
> discuss your real time concerns. You are asking about what this patch has 
> to do with the future real time direction. Who on this thread cares?
> (besides you)

People that don't care about real time related comments, they can stop
reading the thread.. That's the nature of this list ..

Daniel

--
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