> Now that I am working on the configurable maximum RT value patch, I see
> why I did this: we can't hardcode the values like "0 to 99" because that
> 99 is set now via a compile-time define. Even if it defaults to 100, it
> can be a range of values so the comments should be specific and give the
> exact define.
i'm not so sure whether we want to make the last step to make the maximum
RT priority value to be a .config option. Sure we can keep things flexible
so that it's just a matter of a single redefine, but do we really want
users to be able to change the API of Linux in such a way?
the applications which need 1000 RT threads are i suspect specialized, and
since it needs a kernel recompile anyway, it's not a big problem to change
a single constant in the source code - we do that for many other things.
I'd very much suggest we keep the 0-99 range for RT tasks, it's been well
established and not making it a .config doesnt make it any harder for 1000
RT priority levels to be defined for specific applications.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/