moving file descriptor passing into a header

[Lennart Poettering]

On Tue, 13.04.10 18:01, Ryan Lortie (desrt at desrt.ca) wrote:

> On Tue, 2010-04-13 at 23:50 +0200, Thiago Macieira wrote:
> > Em Terça-feira 13. Abril 2010, às 23.27.25, Colin Walters escreveu:
> > > We were discussing some DBus related stuff at this GSettings hackfest,
> > > and related to the GVariant/GBus work, we were thinking it'd be good
> > > to take the file descriptor bits out of the type system, and move them
> > > into a message header.  This makes things significantly saner for
> > > GVariant and anyone else reimplementing the protocol.
> > > 
> > > The API would be something like:
> > > 
> > > int dbus_message_get_unix_file_descriptor (DBusMessage *message, int
> > > index); int dbus_message_append_unix_file_descriptor (DBusMessage
> > > *message, int fd);
> > 
> > How would this work?
> > 
> > The data payload would contain the indices, right? So when you are 
> > demarshalling from the stream, you get ints that are the indices. Then you'd 
> > call the header API to get the actual FD?
> 
> Yes.  Exactly.  Probably we'd want some file descriptor duping going on
> here when you get the fd from the header (unless we have a 'steal' call
> as well).

As mentioned exporting _dbus_message_get_unix_fds() should be fine, as
would be something akin to _dbus_message_put_unix_fds() or so. I think
that question is independant of the demarshalling question.

And the demarshalling question I think is specific to GVariant and hence
shouldn't necessarily reflect on how libdbus itself demarshals things.

> Since you mention it though, another problem is if you try to do
> dbus_message_marshal() followed by dbus_message_demarshal() as a way to
> copy a message.  Up to this point, this copies the entire payload of the
> message without fail.  Now, if you try to do this with file descriptors
> in the message you will end up with an inconsistent result.

Well, I am kind sure not many people do that. The dbus doxygen docs even
question the usefulness of that API call. It's not really an API call
that is the core of what libdbus was designed for, right?

And then, this breaks in *any* case when fds are involved. Regardless if
you demarshal/marshal to/from fds or fd indexes. Because after all the
marshalled blob is exactly the same. The distinction is purely in the
API for it.

> David raised another interesting point:  putting file descriptors into
> the header 
  ^^^^^^^^^^

Well, that's exactly where they already are. It's just that the
DBUS_TYPE_FD demarshallers look things up for you in the header,
resp. the marshalls put things in there for you. Thus making sure the
msg doesn't refer to fds that don't exist in the table.

With the two functions mentioned above we'd expose the header for you
and it is up to GVariant to marshall/demarshal to fd indexes instead of
proper fds...

> has the advantage of not requiring you to explicit mention
> them somewhere in the body.  ie: no need to essentially send the indexes
> (0, 1, 2) in the message if you know that a particular function call
> will always be returning 3 fds -- just use them directly.

Hmm, somehow that mail didn't make it to me yet.

But anyway, I don't think David has a point there. You cannot store fds
on disks, and hence this "extremely nice property" does not matter at
all for msgs where dbus_message_contains_unix_fds() returns TRUE.

Wanting to store msgs with fds on disk is simply nothing anybody would
ever want to do, so discussing that is pointless.

And finally, as I mentioned quite often: the marshalled data simply
includes an index into the fd table of the msg. If you copy the fds
around manually that stays perfectly stable, and you can store it on
disk, memcpy() the marshalled blob as much as you want.

Lennart

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