On Sat, 24.04.10 01:18, Maarten Lankhorst (m.b.lankhorst at gmail.com) wrote: > I'm not sure if I have the right mailing list, since there doesn't > appear to be a a mailing list for rtkit. > > This is a patch that would allow you to set the realtime priority > for another process then the one calling rtkit over dbus. This can > be useful for a 'setsched' like utility, or for wine. Extra > validation on the given pid isn't needed, since verify_process_user > will do this anyhow. Hmm, while I am not strictly against this I don't really see the use for this. The primary reason I came up with rtkit was to allow us to ship PA and similar software with RT privs out-of-the-box and strictly control access to RT for that. A command line tool like you seem to suggest does not really fit into that "out-of-the-box" scheme. What concerns me a bit here is that RT programs must be written in an RT specific style to make sense. That means they must internally know which threads to make RT and which ones not, and when. From the "outside" of the codebase that is difficult to control, especially since information about threads in processes is not really available from the outside on Linux (yes, you can find out about them, but you don't really know which one is which...). Also, RT programs must be RT from beginning of their RT code to the end. If you control their RT scheduling only from the outside this is almost definitely racy. If you want to control RT privs from outside of the process, then the only non-racy way would be to use inheriting across an exec(), which however is something rtkit explcitily prohibits. I am also wondering how many people would use this functionality instead of the lower level, chrt(1) command? So, as mentioned I am not strictly against this, but I'd be interested to hear some good use cases for this, simply because I fear that people might otherwise be invited to write improper RT code. So, convince me! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
