linux-kernel - Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1222983008.2995.205.camel@laptop-eth>
Date:	Thu, 02 Oct 2008 14:30:08 -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 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.

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

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

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

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.

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?

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/