Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable

[Ingo Molnar]

* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> > a fair number of apps assume that there's _at least_ 100 levels of 
> > priorities. The moment you have a custom kernel that offers more than 
> > 100 priorities, there will be apps that assume that there are more than 
> > 100 priority levels, and will break if there are less.
> 
> That's not the same. The apps on my computer right now should not 
> assume that I have 100 priorities.  Since I'm free to work with any 
> kernel that I want.  The customers that ask for a custom kernel are 
> also writing custom apps for a specific product.  Things can be 
> assumed more since the apps are not generic tools that are running on 
> desktops.  In fact, some of these apps require special hardware to 
> work (at least a driver to imitate the hardware).

what i mean is that once there's such a .config option in the generic 
kernel, the cat is out of the bag and there's no way back. In other 
words, increasing the number of priorities is an irreversible change, in 
terms of binary compatibility.

there's absolutely no problem with tweaking your kernel for special 
purposes, and i support all the patches to make it easier (as long as 
there's no cost to the kernel - and there's no such cost so far). But 
whenever some change in the generic kernel has a user-visible effect, 
especially one that is pretty much irreversible, we have to be very 
careful.

(I think in the longer term we might want to do something more clever 
than a blanket increase of the priority levels, we could e.g. put a 
mapping layer between user priorities and kernel priorities, and in fact 
we could make 'user-visible' RT priorities a bit more structured, like a 
hierarchy of levels - while keeping the in-kernel priorities a fast & 
flat thing (which could have more than 100 levels - but that would not 
be visible externally). There's some demand for that, but we'll have to 
wait and see for real demand and real code to crystalise out.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/