21 Jun
2009
21 Jun
'09
9:02 p.m.
On Sun, Jun 21, 2009 at 6:15 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:
On Sun, 21.06.09 11:09, Paul Davis
(paul(a)linuxaudiosystems.com) wrote:
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.
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. 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