moving file descriptor passing into a header

[Lennart Poettering]

On Wed, 14.04.10 10:26, James McKaskill (jmckaskill at gmail.com) wrote:

> 
> So this fd transferring is a bit a new to me. I suppose the idea is
> that returns can then indicate a channel for further transfer of data.
> IMHO using an fd as an int as the means of doing this indirection is
> heavily unportable (it requires that you are on the same unix system
> as the remote - I don't see this idea ever working on windows, and it
> also doesn't work if the remote is on a different machine). Why not
> instead use a similar system as the object path. IE give the
> indirection via a string with a special type that has the port/host to
> connect to (ie an address string like "tcp:host=foobar,port=...").
> This is actually very similar to how ftp does indirection for data
> channels with passive mode.
> 
> The dbus wrapper can then notice the special type and open it up for
> the user to use  in whatever fashion makes sense for the environment
> (ie QIODevice, fd, HANDLE, etc).

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.

There is no need to support every feature of everything on all OSes.

Or read it this way: if you are afraid that you might not be able to
demarshall a unix fd on a win32 machine, then fear no longer: nobody
would want to send you wan on windows in the first place, since he in
the first place couldn't posess one either that could have any meaning
to you!

DBUS_TYPE_UNIX_FD is explicitly only about Unix FDs. No other system
supports any native resource passing transport anyway.

Lennart

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