Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

On Mon, 22.06.09 01:55, Adam Sampson (ats@email-addr-hidden) 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev