On Sun, Jun 21, 2009 at 7:52 PM, Lennart Poettering<[email protected]> wrote: > >> 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* ? > > No. I am not talking about *replacing*. I have asked for adding > support for rtkit to it.
this is quibbling over details. sched_setschedparam() *should* work - its documented as working, the kernel and the higher levels of the OS provide a mechanism to grant priviledge but ... it isn't. so the fix is to add a new call? is this really what are you saying? > The thing is that we cannot safely hand out RT privileges to user > processes without doing acess/rate limiting, watchdog support, calls > into policy systems and so on and so on. hence my comment: RTKit is a baroque solution to a problem that really needs a much more sophisticated solution. >> go and ask linus or ingo and/or whoever is deputized to handle (a) >> scheduling and (b) priviledge control mechanisms. if they come back > Now, if you think you have a better insight into how things should be > done than all of us, then hey, be my guest, why don't you make some > *proper* suggestions how an alternative should be looking like? Asking > for "creative use" and giving the fault to the distributors just > doesn't cut it. you seem to have missed the fact that we went through just such a discussion about 3 years ago when RLIMIT_RTPRIO was first added. there was wide discussion about how to do this. there was specific expectation that distros would provide mechanisms for enabling (and disabling) its use. it was *explicitly* intended to be group-controllable. now you inform us that "it has been decided" that this is bad design. ok, we learn from mistakes and we move on. but everytime this happens, it makes it harder to trust the next choice. and what happened after the last decision was made about how to support/configure this ... almost every media-centric distro enables it out of the box (by user group); no "mainstream" distro does. nobody has created any user-accessible mechanisms to configure it. everything that expected to happen after it went into the kernel has not happened. distro maintainers argue that its a security/robustness problem, and i'm not arguing with this. but there are many things you can configure on any mainstream distro that create security/robustness problems, this one just happens to come with only a text file to configure it and no support from any distro (media centric ones included). > The big problem with RLIMIT_RTPRIO is that it is vulnerable to a > combined fork bomb/busy loop attack. Which I btw documented in the > README (which I figure you didn't read?). Because that is the way it > is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What > did happen is that some distros added an ugly unsecure kludge by > adding "jackuser" group or suchlike that you can add a user to that > had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also > leaves the "out-of-the-box" issue unresolved. except that i could find you posts from people on the l-k mailing list 3 years ago that argued precisely the opposite: that this was *exactly* the solution that was in keeping with other kernel security policy/design issues. > You seem to suggest that I wasn't talking to the kernel folks before I > do something like this. That is wrong. This announcement of mine was > just the last step in doing all this, not the first step. so, who of the half-dozen people from the LAD world who contributed to the discussion that led to RLIMIT_RTPRIO did you include? there seem to be some remarkably short-lived memories in kernel land if people there are so ready to support what is essentially a workaround to what used to be the Right Answer. > Gah. This discussion is so pointless. If you don't want to use in > Jack then fine. The distributions will ship the API and if you don't > make use of it, so be it. It's certainly disappointing, but ultimately > it's not my problem. Lennart, I am not *that* self-centered. I've been confronting issues with Linux support for RT for more than 10 years. I don't give a damn about whether JACK uses this or not. What I care about is the more or less complete failure of the Linux community (by which I include myself, and all of the rest of us) to come with solutions to this problem that actually work and will be supported over more than a couple of years before we move on to the "next approach". I totally understand the goal you have with RTKit, and I applaud you strongly for trying to get this situation fixed. But your solution appears out of the blue in front of one of the two communities most affected by this stuff, and basically ditches the last solution, in which we were quite involved and invested, for a totally different (service/IPC based) solution. Can you not understand why there is some resistance? _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
