21 Jun
2009
21 Jun
'09
11:32 p.m.
On Mon, 22.06.09 01:55, Adam Sampson (ats(a)offog.org) wrote:
I don't think it's a good idea to make the
D-Bus interface the public
API for this, because it assumes that you *can* write a D-Bus service
that gives a thread in another process realtime priority (which is true
for Linux, but not obviously so for other systems, even free ones). If
you want to make it easier for people to write realtime applications, I
think it'd be nicer -- and certainly more portable -- to provide a
librealtimethread, which could try to call your D-Bus service if it's
available, and otherwise fall back to the existing well-tested
approaches for various platforms (e.g. by generalising the code from
jackd).
I am Linux developer. My priority is Linux.
rtkit is Linux-specific, internally it makes use of quite a few
Linux-only features. Which makes it very small and lean. I like it
that way.
You appear to be heading this way with your example
client code in rtkit
anyway -- but please don't tell people to "copy these sources into your
repository", particularly when they contain such blatantly unportable
constructs as "#ifdef __linux__"! What it actually cares about is
whether the D-Bus client library is available, which'd be easy enough to
have a configure script test for.
I guess one can't have one's cake and eat it too.
I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call. Especially since this would be an extra dep to a lot of
software. D-Bus otoh is nowadays so deeply integrated into th system
(heck, we now have it in the init system itself, too, and there
has been work to add kernel code for socket(AF_DBUS)), that it's
available everywhere and on many projects a dep anyway.
Also, the reference client should compile fine on non-Linux, however
it will become a NOP and return ENOSUPP when you call it. I added this
precisely to allow compilation of the code on other OSes and
minimizing the ifdef orgies.
You also need to be careful about licensing. The
license status of D-Bus
-- at least, as of 1.2.14 -- is a mess: the daemon and libdbus-1 are
dual-licensed under the Academic Free License 2.1 and the GNU GPL v2
(only).
Uh? To me it looks as if dbus was AFL/GPL2+ which a verified with a quick
grep over dbus' git repo.
How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
point me to where this is claimed?
rtkit-test.c claims to be GPL v3 or later, which
isn't possible,
since neither the AFL 2.1 or the GPL v2-only are compatible with that
according to the FSF <http://www.gnu.org/licenses/license-list.html>.
The best solution would be for the D-Bus folks to relicense their
client library under a more sensible permissive license...
dbus is GPL2+. When linked against the rkit daemon that gets
practically upgraded to GPL3. Problem solved.
(Incidentally, why the "-Kit" naming? There
seem to be a few packages
like that around now, mostly providing a D-Bus service of some kind.)
Hehe, it's all davidz's fault.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4