From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758472Ab2CBIzX (ORCPT <rfc822;w@1wt.eu>);
	Fri, 2 Mar 2012 03:55:23 -0500
Received: from shards.monkeyblade.net ([198.137.202.13]:52055 "EHLO
	shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752768Ab2CBIzV (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 2 Mar 2012 03:55:21 -0500
Date: Fri, 02 Mar 2012 03:55:09 -0500 (EST)
Message-Id: <20120302.035509.1994457175982020283.davem@davemloft.net>
To: luiz.dentz@gmail.com
Cc: eric.dumazet@gmail.com, javier.martinez@collabora.co.uk,
        rodrigo.moya@collabora.co.uk, javier@collabora.co.uk,
        lennart@poettering.net, kay.sievers@vrfy.org,
        alban.crequy@collabora.co.uk, bart.cerneels@collabora.co.uk,
        sjoerd.simons@collabora.co.uk, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/10] af_unix: add multicast and filtering features to
 AF_UNIX
From: David Miller <davem@davemloft.net>
In-Reply-To: <CABBYNZLwHKd5srzYYzWNL-iaeuH1K31824pY_bjRSbSLkv0QtA@mail.gmail.com>
References: <CABBYNZJ-xxQXAx+ecrkVLqmWFaUVqLcQLj0Jxa3McSLnkLJSJw@mail.gmail.com>
	<20120301.170848.432407217191581288.davem@davemloft.net>
	<CABBYNZLwHKd5srzYYzWNL-iaeuH1K31824pY_bjRSbSLkv0QtA@mail.gmail.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (shards.monkeyblade.net [198.137.202.13]); Fri, 02 Mar 2012 00:55:14 -0800 (PST)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date: Fri, 2 Mar 2012 10:39:24 +0200

> Like I said before there is many projects using AF_UNIX as IPC
> transport, the documentation actually induces people to use for this
> purpose, and many would benefit from being able to do multicast.

You can't have it both ways.

If it's useful for many applications, then many applications would
benefit from a userland library that solved the problem using
existing facilities such as IP multicast.

If it's only useful for dbus that that absoltely means we should
not add thousands of lines of code to the kernel specifically for
that application.

So either way, kernel changes are not justified.