linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

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: <20150415083714.GD16381@kroah.com>
Date:	Wed, 15 Apr 2015 10:37:14 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	John Stoffel <john@...ffel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 12:05:01AM +0200, Jiri Kosina wrote:
> On Tue, 14 Apr 2015, Steven Rostedt wrote:
> 
> > I believe that Linux Plumbers is still accepting MicroConferences. I 
> > wonder if this would be a good one to have. Try to get everyone face to 
> > face and talk about how exactly kdbus should be implemented in the 
> > kernel.
> 
> I personally would even put more emphasis on a session that would first 
> focus on "why", before we look at "how".
> 
> I have already asked about this during the earlier RFC submissions, but 
> the only "take-home message" I took from that discussion was "because it's 
> faster than what we currently have". I don't find that a sufficient 
> justification by itself for something so complex (with potential 
> implications all over the place for the whole Linux ecosystem), especially 
> given the fact we already have sealed memfds zerocopy etc (and I am not 
> even talking about the "infinite set-in-stone userspace API" implications 
> this has).

I wrote many many lines of "why" in the patch submissions, and in the
first email in this thread.  Are any of those specific solutions and
"why" reasons not correct in your opinion?  If so, great, please let me
know.

But to say that no one is focusing on "why" is a slight to those of us
who have been providing just that.

thanks,

greg k-h
--
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/