public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora•co.uk>
To: Chris Friesen <chris.friesen@genband•com>,
	David Miller <davem@davemloft•net>,
	vincent.sanders@collabora•co.uk, netdev@vger•kernel.org,
	linux-kernel@vger•kernel.org
Subject: Re: AF_BUS socket address family
Date: Mon, 02 Jul 2012 17:18:45 +0200	[thread overview]
Message-ID: <4FF1BBD5.8080804@collabora.co.uk> (raw)



On Mon, Jul 2, 2012 at 6:49 AM, Chris Friesen <chris.friesen@genband•com> wrote:
> On 06/29/2012 05:18 PM, David Miller wrote:
>>
>> From: Vincent Sanders<vincent.sanders@collabora•co.uk>
>> Date: Sat, 30 Jun 2012 00:12:37 +0100
>>
>>> I had hoped you would have at least read the opening list where I
>>> outlined the underlying features which explain why none of the
>>> existing IPC match the requirements.
>>
>> I had hoped that you had read the part we told you last time where
>> we explained why multicast and "reliable delivery" are fundamentally
>> incompatible attributes.
>>
>> We are not creating a full address family in the kernel which exists
>> for one, and only one, specific and difficult user.
>
>
> For what it's worth, the company I work for (and a number of other
> companies) currently use an out-of-tree datagram multicast messaging
> protocol family based on AF_UNIX.
>
> If AF_BUS were to be accepted, it would be essentially trivial for us to
> port our existing userspace messaging library to use it instead of our
> current protocol family, and we would almost certainly do so.
>
> I'd love to see AF_BUS go in.
>
> Chris Friesen
>

Hi Chris,

Thanks a lot for your comments and feedback.

We tried different approaches before developing the AF_BUS socket family and one
of them was extending AF_UNIX to support multicast. We posted our patches [1]
and the feedback was that the AF_UNIX code was already a complex and difficult
code to maintain. So, we decided to implement a new family (AF_BUS) that is
orthogonal to the rest of the networking stack and no added complexity nor
performance penalty would pay a user not using our IPC solution.

Looking at netdev archives I saw that you both raised the question about
multicast on unix sockets and post an implementation on early 2003. So if I
understand correctly you are maintaining an out-of-tree solution for around 9
years now.

We developed AF_BUS to improve the performance of the D-Bus IPC system (and our
results show us a 2X speedup) but design it to be as generic as possible so
other users can take advantage of it.

It would be a great help if you can join the discussion and explain the
arguments of your company (and the others companies you were talking about) in
favor of a simpler multicast socket family.

The fact that your company spent lots of engineering resources to maintain an
out-of-tree patch-set for 9 years should raise some eyebrows and convince more
than one people that a simpler local multicast solution is needed on the Linux
kernel (which was one of the reasons why Google also developed Binder I guess).

[1]: https://lkml.org/lkml/2012/2/20/84
[2]: https://lkml.org/lkml/2003/2/27/150
[3]: http://lwn.net/Articles/27001/

Thanks a lot and best regards,

Javier

             reply	other threads:[~2012-07-02 15:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-02 15:18 Javier Martinez Canillas [this message]
2012-07-03 16:52 ` AF_BUS socket address family Chris Friesen
2012-07-03 17:18   ` Chris Friesen
  -- strict thread matches above, loose matches on Subject: below --
2012-06-29 16:45 Vincent Sanders
2012-06-29 18:16 ` Chris Friesen
2012-06-29 19:33   ` Ben Hutchings
2012-06-29 18:45 ` Casey Schaufler
2012-06-29 23:22   ` Vincent Sanders
2012-06-29 22:36 ` David Miller
2012-06-29 23:12   ` Vincent Sanders
2012-06-29 23:18     ` David Miller
2012-06-29 23:42       ` Vincent Sanders
2012-06-29 23:50         ` David Miller
2012-06-30  0:09           ` Vincent Sanders
2012-06-30 13:12           ` Alan Cox
2012-07-01  0:33             ` David Miller
2012-07-01 14:16               ` Alan Cox
2012-07-01 21:45                 ` David Miller
2012-06-30  0:13         ` Benjamin LaHaise
2012-06-30 12:52           ` Alan Cox
2012-07-02 14:51             ` Vincent Sanders
2012-07-02  4:49       ` Chris Friesen
2012-07-05 21:06     ` Jan Engelhardt
2012-07-06 18:27       ` Chris Friesen
2012-06-30 20:41 ` Hans-Peter Jansen
2012-07-02 16:46   ` Alban Crequy
2012-07-05  7:59 ` Linus Walleij
2012-07-05 16:01   ` Daniel Walker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FF1BBD5.8080804@collabora.co.uk \
    --to=javier.martinez@collabora$(echo .)co.uk \
    --cc=chris.friesen@genband$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=vincent.sanders@collabora$(echo .)co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox