Lennart Poettering wrote: > On Mon, 22.06.09 23:46, Jörn Nettingsmeier (netti...@folkwang-hochschule.de) > wrote: > >>> What is so difficult to understand that rtkit is not intended to be a >>> solution for hardcore rt users? >>> >>> rtkit is not for you! >>> >>> Let me repeat this: >>> >>> RTKIT IS NOT FOR YOU! >> this is getting childish. my claim is: if you give rt to a user, you >> enable him to fuck the machine up. that's a law of nature. you can do >> all kinds of very clever things and try to have a very fast watchdog, >> but it doesn't prevent abuse. > > That is simply bogus. > > With the reset-on-fork kernel patch in place you can perfectly > supervise an RT process and it cannot evade you. If the system becomes > unresponsive (which is all that we try to detect), then we can > demote/kill everyone who's misbehaving.
you don't need to fork in order to do wreak havoc. how do you make sure you know which processes (i.e. which executables) deserve rt rights? hash them? and whatever you do, the moment the user loads a user-defined plugin from a user-controlled location (such as a privately installed LADSPA plugin), you are utterly hosed. or am i missing something fundamental here? in which case please enlighten me. btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you define a maximum amount of time that can be spent in rt mode, per user? or per process? or per group? if per user, how is scheduling fairness accomplished? does the first rt process grab as much as it wants, and then another rt process gets demoted by rtkit because the user used up their rt slice? _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev