Hello Darren, > I disagree. The point of real-time is to provide user-space with more control > of what get's run, when, instead of something else - including system > interrupts, etc. For instance, if networking should take a higher priority > than their application, but disk i/o should take a lower one, the user needs > to be able to control that. chrt is the correct approach for -rt in my > opinion. I believe this depends on the environment where the RT-kernel is used. Therefor this might be true for Realtime Desktop/Server applications, but, for RT-Embedded systems it is possible (likely) that the entire kernel is pre-configured for 1 single purpose, and that some developer wants to set the priorities for that purpose only. In that case there is usually no user that cares anything about what is running on the system, as long as his device works, so that user will never come to the idea to use 'chrt'. In these case the default priorities at 50 are useless and the developer has to have a way to configure the priorities. So I understand the question of Juergen. To suit my needs, I did this by just patching the kernel thread priorities at the places where they are started. (And I am still happy with my solution. Note that because it is very application specific, I never expect a patch like this to get to the mainline) Kind Regards, Remy - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
