Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965868AbbDWNFy (ORCPT ); Thu, 23 Apr 2015 09:05:54 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:55807 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbbDWNFx (ORCPT ); Thu, 23 Apr 2015 09:05:53 -0400 Date: Thu, 23 Apr 2015 15:05:48 +0200 From: Greg Kroah-Hartman To: Linus Torvalds , Andrew Morton Cc: Arnd Bergmann , ebiederm@xmission.com, gnomes@lxorguk.ukuu.org.uk, 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: <20150423130548.GA4253@kroah.com> References: <20150413190350.GA9485@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150413190350.GA9485@kroah.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3101 Lines: 65 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 -- 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/