Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966269AbbDWOS3 (ORCPT ); Thu, 23 Apr 2015 10:18:29 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:53637 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752392AbbDWOS2 convert rfc822-to-8bit (ORCPT ); Thu, 23 Apr 2015 10:18:28 -0400 Date: Thu, 23 Apr 2015 15:17:53 +0100 From: One Thousand Gnomes To: Greg Kroah-Hartman Cc: Linus Torvalds , Andrew Morton , Arnd Bergmann , ebiederm@xmission.com, teg@jklm.no, jkosina@suse.cz, luto@amacapital.net, linux-kernel@vger.kernel.org, daniel@zonque.org, dh.herrmann@gmail.com, tixxdz@opendz.org Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150423151753.628841d1@lxorguk.ukuu.org.uk> In-Reply-To: <20150423130548.GA4253@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2581 Lines: 54 > Alan, and others, want a tiny, generic, multi-cast IPC method that also > works across networks.  They feel that this is something that D-Bus I never said - across networks. And locally it has been done, even microcontrollers have done it. > Lots of people have said they want something like this for years, but > that doesn't address the issue here with kdbus, which is a very specific > solution for a very common and wide-spread usage model that Linux You've missed off a variety of important points that have been raised - whether its a dumb model performancewise compared with using it to set up a memfd or similar - cgroup interactions - the heavyweight nature of going via get_user_pages and __vfs_read raher than just assuming message sizes are sensibly constrained and could far better just be allocated and copied to a refcounted kernel buffer - exposure of capabilities and how you futureproof it > userspace relies on today.  I too would love to see such an IPC be > created, and two years ago thought it would be possible to achieve > here.  But over time, and in working with the D-Bus model and > requirements, it just didn't happen here.  Given that no one has ever > been able to accomplish such a thing in the past means that it's either > impossible to do, or that no one really wants such a thing bad enough to > actually do the work :) > > Did I miss anything else here?  Are there any technical reasons I'm > forgetting about for why this can't be pulled in as-is for this merge > window? Like the outstanding NACKS ? Greg - you are sounding like you have some kind of special entitlement to ignore the way this works for everyone else. If you are feeling frustrated, annoyed and led up several avenues at once then welcome to the world of every other submitter who doesn't think have some kind of magic stage door pass to get their crap in the kernel when there are core maintainers asking hard and unanswerd questions and who have nacked it. There's no huge hurry. There are a bunch of things like the interactions with cgroups, and the privilege and capability model which need careful examination. Slipping it one release to get that right isn't a big deal - it's not even as if you can't use hardware without it as with a driver missing a merge - this is just a performance tweak. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/