Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753820AbbG3SNI (ORCPT ); Thu, 30 Jul 2015 14:13:08 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:35313 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750877AbbG3SNG (ORCPT ); Thu, 30 Jul 2015 14:13:06 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Thu, 30 Jul 2015 11:12:44 -0700 Message-ID: Subject: Re: Revisit AF_BUS: is it a better way to implement KDBUS? To: cee1 Cc: LKML , Greg KH , Lennart Poettering , David Herrmann , One Thousand Gnomes Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2277 Lines: 52 On Thu, Jul 30, 2015 at 6:09 AM, cee1 wrote: > Hi all, > > I'm interested in the idea of AF_BUS. > > There have already been varies discussions about it: > * Missing the AF_BUS - https://lwn.net/Articles/504970/ > * Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel - > http://lwn.net/Articles/537021/ > * presentation-kdbus - > https://github.com/gregkh/presentation-kdbus/blob/master/kdbus.txt > * Re: [GIT PULL] kdbus for 4.1-rc1 - https://lwn.net/Articles/641278/ > * The kdbuswreck - https://lwn.net/Articles/641275/ > > I'm wondering whether it is a better way, that is, a general mechanism > to implement varies __Bus__ orientated IPCs, such as Binder[1], > DBus[2], etc. I find myself wondering whether an in-kernel *bus* is a good idea at all. Creating a bus that unprivileged programs are allowed to broadcast on (which is kind of the point) opens up big cans of worms. Namely: what happens when producers produce data faster than the consumers consume it? Keep in mind that, with a bus, this scales pretty badly. Each producer's sends are multiplied by the number of participants. At some point soon, I'm planning on playing with Fedora Rawhide with kdbus. Anything's possible (maybe), but I'd be rather surprised if it holds up under abuse of the bus. ISTM kdbus is trying to solve a few problems that really can't be solved together: it wants (mostly) reliable delivery, it wants globally ordered messages, and it wants broadcasts. That means that, if message N gets broadcast, then, until *every* recipient has received message N, message N and all of its successors need to be buffered somewhere. I see how this works (by massive use of tmpfs), but I don't see how it's going to work *well*. Certainly approximate solutions are possible, but is the kernel really a good place to arbitrate which message survive under pressure? People can throw code at this all they want, but ISTM the problem that the dbus community wants to solve doesn't actually admit a scalable solution. --Andy -- 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/