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.0810021749230.24442@gandalf.stny.rr.com>
Date:	Thu, 2 Oct 2008 18:28:36 -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:

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

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

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

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

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

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

The topic for mainline patch threads needs to stay focused on mainline. 
Not on out of tree branches. When the rest of real time is in mainline, 
then sure, you can discuss those concerns then. But until that happens, 
keep to the topic of the thread. Which for now is not real time.

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