On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote: > > It would need to do more that that. It may have to calculate the value > > that it returns, as the internal value may be different with different > > kernels. > > back to 'prio'... the 'prio' accessible from the program > should be the same 'prio' that we're storing inside task_struct. Its not, task_struct::prio is an entirely different value than the one used in sched_param::sched_priority / sched_attr::sched_priority. And the 'problem' is, prio is only relevant to SCHED_RR/SCHED_FIFO tasks, we have more classes. > No extra conversions. We're not going to add runtime/space overhead to the kernel just because someone might maybe someday trace the kernel. That leaves the option of either tracing the kernel internal value and userspace will just have to deal with it, or making the tracepoint more expensive by having it do the conversion. Now the big question is, what do we do when we add/extend a scheduling class and have more parameters? We cannot change the tracepoint because userspace assumes format. And I simply refuse to add a second -- because that will end up being a third and fourth etc.. -- tracepoint right next to it with a different layout. Note that we just did add a class, we grew SCHED_DEADLINE a few releases ago, and that has 3 parameters (or 6 depending on how you look at it). You currently cannot 'debug' that with the existing tracepoints. In short, I loathe traceevents, they're more trouble than they're worth. Now I do love the infrastructure, its very useful debugging, but that's all with local hacks that will never see the light of day. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
