Unix FD Passing
mzqohf at 0pointer.de
Wed May 20 16:35:08 PDT 2009
On Wed, 20.05.09 19:17, Havoc Pennington (hp at pobox.com) wrote:
> On Wed, May 20, 2009 at 7:06 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> > mm, problem is that nego happens inside of dbus_connection_open(),
> > doesn't it? flags like that would have to be available that early.
> > I.e. we'd need:
> > dbus_connection_open_with_flags()
> > dbus_connection_open_private_with_flags()
> > dbus_bus_get_with_flags()
> > dbus_bus_get_private_with_flags()
> > Which is bearable but still ugly.
> It looks to me like connection_open() does no IO, but bus_get does. So
> bus_get would need a new variant.
> Flags vs. feature level:
> * flags allows non-feature-level-related flags
> * flags can only express up to 32 feature levels (if no other use of
> flags is made)
> * does FEATURE_LEVEL_1 | FEATURE_LEVEL_2 really make sense?
> Comes down to whether we want to support selectively enabling each
> feature, or just do the feature levels with say all features in a
> given stable libdbus release.
If we do this then I'd vote for going with flags that explicitly map
to each feature. Doing "FEATURE_LEVEL" style all-in-one 'packages' of
features doesn't really reflect what bindings might want.
For example, most likely some high-level languages (Java?) might not
be interested in supporting Unix FD passing at all. AFAICS there is no
equivalent to close() in Java, so you'd have an int you cannot really
make any sense of, and not even get rid of. However, they might be
interested to support later features (such as float32). Allow them to
support that without having to support Unix FD!
I'd guess 32 bit are enough for the forseeable feature. After all
since 2001 (or whenever did D-Bus get started) it took 8 years for the
first negotion-needing feature to pop up. And beyond that only one
feature (float) is likely to appear in the near feature. At this rate
with 32 bits we should have flag space for the next 120 years at
One could even 'fake' additional flags by having a macro that
translates type codes to flags. i.e.
For most types that macro would return 0.
Please note however, that I am still not convinced that this kind of
libdus<->client nego is really necessary and a good idea. ;-)
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus