Messages in this thread | | | Date | Fri, 02 Mar 2012 17:34:50 +0100 | From | Javier Martinez Canillas <> | Subject | Re: [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX |
| |
On 03/02/2012 02:13 PM, Eric Dumazet wrote: > Le vendredi 02 mars 2012 à 10:27 +0100, Javier Martinez Canillas a > écrit : > >> We are the most interested in using a facility already found in the >> kernel, we will try ZeroMQ as Stephen suggested and TIPC but really >> didn't find an IPC mechanism that fits our needs. The most important >> issue right now is the fd passing for D-bus application doing >> out-of-band communication. > > Why on earth the needed D-Bus IPC should use a single kernel mechanism ? > > I mean, of course AF_INET cannot pass fd around and never will. > Of course AF_UNIX cannot use multicast and never will. > Of course shared memory wont pass fds around and never will. > ... Add other impossible combinations as you want. > > There are reasons fd passing is hard to implement. I find stuffing this > functionality in AF_UNIX was a bad design choice from the very > beginning. >
Yes, can't say that everyone is happy with fd passing. It seems like a workaround since D-bus didn't scale for big chunks of data IMHO.
> Instead of pushing extra complexity to a single kernel component, why > not trying to use a combination of existing, well designed and supported > ones ? >
You are right, maybe a combination of IPC mechanism could be used.
Basically we have this scenario:
1- Most applications today uses D-bus as an IPC system and is a central part of the Linux desktop.
2- The transport layer used by D-bus is not performance sensitive basically due:
a) high number of context switches required to send messages between peer. b) the D-bus daemon doing the routing and being a bottleneck of the whole. c) amount of messages copied between kernel space and user space.
3- We still haven't found a single kernel IPC mechanism or a combination of IPC mechanism that can address this issue.
This is a real concern in the Linux embedded world. Since Linux based products wants to use well probed software components found in Linux distros such as oFono, BlueZ, Pulseaudio, Connman and Telepathy to name a few. All of them uses D-bus to expose its API to other applications.
I'm not saying that extending AF_UNIX for supporting multicast is the best approach but what I'm saying is that we should find a solution to this problem.
PD: I'm cc'ing Marcel Holtmann so hopefully he can add his point of view to the problem (and possible solutions).
I know that Marcel is also working on improving the D-bus system but moving to the kernel some tasks made by the D-bus daemon today.
Regards, Javier -- 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/
| |