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]

Date:	Thu, 2 Oct 2008 17:05:10 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Daniel Walker <dwalker@...sta.com>
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, 2 Oct 2008, Daniel Walker wrote:
> > 
> > What Ingo is telling you is:
> > 
> >   - RT needs threaded interrupts.
> > 
> >   - Threaded interrupts do not need RT
> > 
> > My dog is an Italian Greyhound.
> > 
> > Italian Greyhound is a dog, but
> > a dog is not an Italian Greyhound.
> 
> My comments are basically bidirectional , so what your saying doesn't
> make any sense .. I said basically, that dogs and "Italian Greyhounds"
> have _some_ connection .. Why are we even debating this.

Let's look at your original comments:

> I'm not clear on your direction here.. I don't have a problem with a
> mass driver audit, which I think is what your suggesting with this patch
> set .. However, a mass audit like that would push a fully real time
> system out for quite some time..

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

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

The strong reaction from Thomas is that you just brought up something that 
is completely off topic.

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.

Actually my analogy with dogs and IG's is wrong. The pipe and crap analogy 
is better. Crap uses pipes to get out of the house. But if I'm talking 
about pipes, I don't want to hear about crap.

We are debating this because YOU brought it up!

-- Steve

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