Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756574AbbDOV4x (ORCPT ); Wed, 15 Apr 2015 17:56:53 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:43822 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756392AbbDOV4p (ORCPT ); Wed, 15 Apr 2015 17:56:45 -0400 Date: Wed, 15 Apr 2015 22:56:11 +0100 From: One Thousand Gnomes To: Greg Kroah-Hartman Cc: Steven Rostedt , Richard Weinberger , Andy Lutomirski , Al Viro , "Eric W. Biederman" , Linus Torvalds , Andrew Morton , Arnd Bergmann , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415225611.0c256ea6@lxorguk.ukuu.org.uk> In-Reply-To: <20150415173145.GA26146@kroah.com> References: <8738434yjk.fsf@x220.int.ebiederm.org> <20150413194217.GA10837@kroah.com> <20150413202233.GR889@ZenIV.linux.org.uk> <20150415084812.GG16381@kroah.com> <20150415122555.74258d63@lxorguk.ukuu.org.uk> <20150415154551.GE6801@home.goodmis.org> <20150415163520.GA25105@kroah.com> <20150415130649.6f9ab20f@gandalf.local.home> <20150415173145.GA26146@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=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3438 Lines: 79 On Wed, 15 Apr 2015 19:31:45 +0200 > Don't make idle comments, the tty layer is far more complex and larger > than the kdbus code, with much nastier issues and problems. And we > handle that just fine :) The tty layer is the way it is because of design decisions dating back 20 years that were (with hindsight) wrong coupled with the fact that POSIX took a lot of the behavioural guarantees from an armwaving claim about what Unix(tm) implemented without thinking about how to implement them (as far as I can tell - given many of the guarantees are broken in Unix!) > I'll again refer to ALSA here, no one writes a "raw" ALSA program, they > all use the library to interact with the kernel. Do that here, there > are wonderful dbus libraries out there, for all languages. Use them > instead. Agreed entirely - I don't disagree that we need a fast messaging layer. The question is what bits belong in kernel. Go wants one, JMS wants one, porting from stuff like QNX wants one (although they use the POSIX API on QNX), MPI wants one (but with some useful and subtly different semantics), various embedded things from tiny uKernels want one. The question is what the kernel bit should actually look like, and how many we need. My guess is that we actually have three of the big use cases covered - futexes and shared memory cover the tiny uKernel emulation bits (and on a lawnmower engine sized ARM thats probably the only way to get the speed approaching that of a tiny rtos) - posix queues cover things like QNX porting - publish/subscribe - via tmpfs but we don't cover - multicasting - some types of credential and authority passing - scatter/gather without excessive userspace wakes > > Is there a reason that this patch must go in this merge window? > > What makes this merge window any different from any other? Again, I > explained why I asked it to be merged at this point in time. If people > have technical issues with it, I'll be more than glad to work them out > and merge it later, there's no "hard and fast deadline" anyone is asking > for here. The problem I have is that every time someone points out a fundamental design issue you simply say "Why haven't you reviewed 13,000 lines of code". I haven't given it an in depth review for the same reason as if someone posted 13,000 lines of "I've got an awesome new file system which uses a FAT and 8.3 file names". There's some more pressing concerns to sort first. The fact it's complex and hard to follow also doesn't encourage review. And the fact Al tried to read it and is asking for help really worries me 8) > > > Having something this controversial take place during the merge window > > suggests its a bit premature to push in now. > > "take place"? Have you been ignoring these patches posted numerous > times for many months? This is the point in time to ask for code to be > merged, just like any other code, nothing is special here. Well - you've asked. I see two NACKs from people with great taste. So I think the next step is to defer trying to submit it and work through the fact that Al can't follow the locking, and other people don't believe the security model is maintainable. 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/