Messages in this thread | | | Subject | Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers | From | Daniel Walker <> | Date | Thu, 02 Oct 2008 16:24:02 -0700 |
| |
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
| |