Date: Thu, 23 Apr 2015 15:17:53 +0100
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Arnd Bergmann <arnd@arndb.de>, 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
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@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/