Re: DBus on "other" platforms
René J.V. Bertin <[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <[email protected]> |
On Thursday May 12 2016 18:18:10 Simon McVittie wrote: > > So we'd be looking at patching GLib and libdbus? > > You'd be looking at making changes to GLib and maybe libdbus that, > unlike disabling EXTERNAL authentication, are of a quality that can go > upstream, at which point you no longer need to carry a patch that > reduces security, and everyone wins. That's what I meant. Patches aren't necessarily kludges ;) > > It's possible that libdbus already knows how to do credentials-passing > on OS X. Try running "test/test-dbus-daemon --tap" (to get this > compiled, you have to build dbus with --enable-modular-tests, which > requires GLib). If you see something like > > # ProcessID of this process is 12345 > # UnixUserID of this process is 678 I'm seeing this: /creds: Failed to start message bus: Socket name too long Is that because I already have my session bus running? > It looks as though this may still be a real issue: poll() on Darwin/OS X > seems to just be very poorly implemented, unless something has changed > in the last few years. I'm surprised by this, because surely it works > fine on the *BSD from which Darwin was forked... I guess the poll() function invokes some kernel function, and OS X has a very different kernel than what's common on *BSD ... > In practice D-Bus actually only polls sockets, pipes, inotify > descriptors (Linux and anything that copied the API, like QNX) and > kqueue descriptors (FreeBSD and anything that copied that API), so we > might even be able to get away with using Darwin's broken poll(). Because you're not polling devices, right? > On the > other hand, the typical symptom of it not working would be a busy-loop, > which is not what we want. The broken poll check doesn't busy-loop on /dev/null, if that's any consolation :) How soon would one hit the busy-loop or other issues? Is there a unittest that does some form of stress-testing of poll() without requiring the running dbus daemon to be built under the assumption poll() works? R. _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus