Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752146AbbGaJxA (ORCPT ); Fri, 31 Jul 2015 05:53:00 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:35526 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbbGaJw6 (ORCPT ); Fri, 31 Jul 2015 05:52:58 -0400 MIME-Version: 1.0 In-Reply-To: References: From: cee1 Date: Fri, 31 Jul 2015 17:52:38 +0800 Message-ID: Subject: Re: Revisit AF_BUS: is it a better way to implement KDBUS? To: Andy Lutomirski 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: 1306 Lines: 33 2015-07-31 2:12 GMT+08:00 Andy Lutomirski : > > 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*. For broadcast, what will the kernel behave if: 1. Lots of processes open netlink socket (to receive uevents), but not consume it. And someone continues to trigger uevents. 2. Lots of processes open inotify to monitor a directory, but not consume the events. And someone continues to operate files under the directory. ... I guess it may have to drop some data if the producer produces too fast(or the consumers consume too slow). What it needs may be a chance for recipients to know some broadcast data lost. -- Regards, - cee1 -- 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/