Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Mon, Apr 13, 2015 at 09:03:50PM +0200, Greg Kroah-Hartman wrote:
> The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:
> 
>   Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/kdbus-4.1-rc1
> 
> for you to fetch changes up to 9fb9cd0f4434a23487b6ef3237e733afae90e336:
> 
>   kdbus: avoid the use of struct timespec (2015-04-10 14:34:53 +0200)
> 
> ----------------------------------------------------------------

Given this has been a crazy email thread, let's try to figure out what
the status is here.

Al Viro pointed out some odd locking (r/w lock only used in write mode),
and asked for some more documentation / description of the object model
used here.  David provided that, and will send a minor fix for the rw
lock, so I think that issue is now resolved.  David has created a few
other minor changes based on Al's review that I will forward on later.

Andy's concerns about the capability stuff has been hashed out in
multiple threads here.  The kernel code isn't buggy as-designed or
implemented from what we can all tell, it's just that the new
functionality isn't liked by everyone, which is totally fair, but not a
reason to declare that the function isn't useful.

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
might be able to use in the future in userspace to build on top of. 
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
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?

As for merging this, due to some changes in the vfs tree, specifically
due to 5d5d56897530 ("make new_sync_{read,write}() static"), after the
kdbus code is merged with your latest tree, it can cause problems, as
reported by Sergei Zviagintsev.  I didn't want to rebase anything, and
solving the issue against 3.19 would require us to export __vfs_read(),
as Al already did in your tree, so you can just merge it, and then apply
the patch I'll send in response to this message for it, which resolves
the issue.

thanks,

greg k-h