linuxaudio.org

On Mon, 22.06.09 01:55, Adam Sampson (ats@offog.org) wrote:
> I don't think it's a good idea to make the D-Bus interface the public

quoted text
> 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

quoted text
> 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

quoted text
> -- 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,

quoted text
> since neither the AFL 2.1 or the GPL v2-only are compatible with that

> according to the FSF .

> 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

quoted text
> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev