Fwd: moving file descriptor passing into a header

[Lennart Poettering]

On Wed, 14.04.10 11:03, James McKaskill (jmckaskill at gmail.com) wrote:

> I missed the reply to all button.
> 
> > This is about passing any kind of fds (files, sockets of all kinds,
> > device handles, fs fifosq, socketpair(), pipe(), inotify(), epoll() --
> > whatever kind of fd your OS supports) . And yes, this is not portable
> > beyond Unix. That's why the type is called DBUS_TYPE_UNIX_FD, not
> > DBUS_TYPE_FILE or so.
> 
> I can understand wanting to transfer a pipe or a socket across as a
> means of transferring data out of band (and if that is all, then you
> can do this easily via a similar mechanism as ftp passive - give an
> address that remote should connect to). But seriously the other random
> types as well? Is there actually any requirement for these?

One of the primary use cases for this was bluetoothd's audio
handling. Something where excessive copying is really not
desired. bluetoothd passes AF_BLUETOOTH sockets to
PulseAudio. bluetoothd will set things up first and the PA just needs to
do the actual audio data processing.

Generalizing this: a server app takes or creates network connections on
behalf of some hardware, other host or local software and passes that
off to other processes, after some initial processing.

And that is actually quite a common case since quite a few protocols
have two phases: auth/setup and the main part. And D-Bus now allows you
to easily split that up between processes, for whatever reason you might
have (priviliges, robustness, whatever).

Also, instead of passing around sockets you can also pass around device
fds, in case some fds might need priviliged setup and you want to pass
it off to unpriviliged code or suchlike (which is also the case in
bluetoothd).

> Up until now dbus messages have just been straight binary blobs. This
> is advantageous for a number of reasons (os agnostic, works between
> disparate systems, can be memcpy, serialised to file etc). IIMHO that
> is a _very_ handy feature, and shouldn't be removed without serious
> thought. If I may be so blunt transferring fds like this directly
> feels like a hack that is bending the protocol to fit a particular
> language's interface, doesn't fit in with the protocol, and is just
> going to cause more trouble than its worth.

Well I disagree. It fits quite naturally I believe. And it got merged
ages ago.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4