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: <alpine.DEB.1.10.0810021652370.24442@gandalf.stny.rr.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ