[Patch] Moving FD passing into the header

[Lennart Poettering]

On Tue, 22.06.10 12:32, Christian Dywan (christian at lanedo.com) wrote:

> 
> Am Mon, 21 Jun 2010 10:17:25 -0400
> schrieb Colin Walters <walters at verbum.org>:
> 
> > On Fri, Jun 18, 2010 at 3:38 PM, Havoc Pennington <hp at pobox.com>
> > wrote:
> > >
> > > However I don't really get the argument about extending the type
> > > system being disruptive, since there are other extensions also in
> > > progress. You may as well dump in another one (in fact getting them
> > > all done at once so bindings would update in one shot, would be an
> > > admirable goal ... the feature negotiation could even be "typesystem
> > > 2.0" instead of allowing subsets/combinatorics of the extensions).
> > 
> > Okay...that does lend itself to the suggestion of keeping the fd
> > passing as an explicit type, and getting the maybe type in, and
> > calling that typesystem 2.0 then.  If we're taking this approach, then
> > that raises the question of other extensions, but there's nothing
> > really else in the cards, is there?  Besides float I guess, but that
> > one I think is fairly fringe.
> 
> That still leaves the aspect that it will no longer be possible to
> serialize and copy messages according to their signature. FD is
> not a flat type in the same way as an integer. It can't be stored on
> disk. It can't be passed over the network. The only thing you can do is
> pass it over the bus, which is what the explicit API allows.
> 
> The breach in consistency will be the same in GVariant, which can
> serialize all contained types *except for* h.

Well, GVariant is not the same as the D-Bus type system. There will
always be features one has the other hasn't. Sometimes GVariant might
support more, sometimes the D-Bus type system might support more, simply
because the other one hasn't caught up. But that's fine. GVariant must
have proper support for future extensions of the type system. And when
it reads a type it doesn't know how to handle, it must return a clean
error. And D-Bus kinda already has that with the nego stuff I
implemented.

So, accept that the dbus type system and the gvariant type system will
always differ, it is completely OK if both support a different set of
features as long as a clear error and upgrade path is available.

And again, and I said it a gazillion of times: nothing stops you from
serializing/deserializing the unix fd stuff not as unix fd, but as index
into the fd table. Then, things would behave almost identical to what
your patches offer, except that methods that carry unix fds are properly
typechecked and have complete introspection data. You could support that
just fine in GVariant with minimal work.

> And of course the type system stops being platform agnostic.

That's irrelevant. On platforms where unix fds are not supported nobody
would ever even think about sending an unix fd, or receiving one,
because, well, they just don't exist. This is a real non-issue. Some
folks always come up with the question "Hey, what happens if my Win32
program receives an unix fd via D-Bus?", but the whole question is
bogus, because that can never happen because nobody could even send you
one.

Lennart

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