On Sun, Jun 21, 2009 at 6:15 PM, Lennart Poettering<[email protected]> wrote: > On Sun, 21.06.09 11:09, Paul Davis ([email protected]) wrote: > >> > Just a quick announcement: >> > >> > I just moved into Fedora Rawhide a little daemon called "RealtimeKit" >> > which will be enabled by default, and since it is now a dependency of >> > PulseAudio and things work how they work this will then not only be >> > available in Fedora 12 but also sooner or later in the other >> > distributions as well, installed by default. >> > >> > So what does this do? It's a simple policy daemon that hands out >> > SCHED_RR scheduling to normal user processes/threads that ask for it. >> >> This appears to be a baroque mechanism designed to solve a problem >> suspectible to vastly simpler solutions. > > Simpler solutions? I am listening! What would a "simpler solution" be, > that doesn't suffer by all the issues I pointed out in the README? > > Also, what's baroque with this? I mean, really, this offers an API of > two tiny functions. Not sure why you'd call that baroque?
the API is simple. the implementation that the API sits on top of it baroque. not yours, necessarily, but the combination of RTKit and Ingo's patch. Baroque doesn't necessarily mean "huge, vast and incomprehensible". it can just mean "overly intricate for the task at hand". i definitely led you astray with the reference to the jack source code. firstly because you seem to have imagined that by mentioning the use of POSIX i was making some kind of claim about POSIX correctness - not sure what kind of game that it is. but secondly and more importantly because the code now looks reasonably clean as a result of me ditching all the crap that we needed on various older versions of linux. yes, it is indeed now just as simple as OS X. in the code only, of course. i had forgotten to check the current state of things before referring to it. >All I kindly ask for is to ease the distributors life by > adding a tiny bit of fallback code that does a tiny call into rtkit in > case sched_setschedparam() fails with EPERM and is #ifdef as __linux__ > && HAVE_DBUS and is also contorollable as a compile-time configure > option. so, sched_setschedparam(), a documented, implemented and demonstrably functional call fails in some cases. and your proposal is to replace this well-established API with a new API that doesn't actually accomplish anything new except *WORKING* ? i'm sorry but to me this is just absurd. the call is there, it works (for a user with certain priviledges granted), and has a reasonably long pedigree. why should fixing the problem with priviledge granting be accomplished with a different call to get the same scheduling priority, a call that relies on new kernel functionality that isn't necessary for the sched_sp() approach? this is applying a band-aid to a deeper solution, and its because of this that its hard to support it. go and ask linus or ingo and/or whoever is deputized to handle (a) scheduling and (b) priviledge control mechanisms. if they come back and say "we think this is an appropriate solution and we don't intend to address this any further in terms of kernel mechanisms" then the conversation moves on to the next step - why are distributions not being more creative with the priviledge granting mechanism that is already in place? my reading of ingo's patch is that its mechanism, not policy (as usual for the kernel), and its really *mostly* duplicating facilities that are already intended to be accessed via sched_setschedparam(). apparently, you feel otherwise. the thing is lennart that the kernel guys and others interested in regular user access to SCHED_(!OTHER) put a lot of effort into the current rlimit mechanism as the appropriate solution. none of the mainstream distributions have bothered to make it configurable, usable etc. etc. fixing that by creating a new API just seems ... odd at best, and counter-productive at worst. --p _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
