* Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On 10/07/2010 05:58 PM, Frederic Weisbecker wrote: > > I really feel uncomfortable with this tracepoint/ABI problem.... > > Mathieu suggested we start a user library that could handle these > > changes when they are really necessary. > > > > Thoughts? > > > > (Adding Tejun in Cc). > > Given that tracepoints are supposed to make internal operation > visible. I don't think it's a good idea to make it part of fixed ABI. Yep, exactly. OTOH since it exports information we can do disciplined versioning and extensions only - i.e. leave the old power events around, add the new ones with new distinct names, and phase out the old ones in a kernel cycle or two. It's not hard to do. That way apps can support old kernels too (if they want to), but new events as well - and all in a controlled, non-disruptive manner. More importantly, the kernel wont have cruft and will have no ABI restrictions - the only 'restriction' is to treat information in an append-only manner (i.e. change the event name if you change it materially) - and that's not a big deal here. The fundamental thing about tracing/instrumentation is that there are no deep ABI needs: it's all about analyzing development kernels (and a few select versions that get the enterprise treatment) but otherwise the half-life of this kind of information is very short. So we dont want to tie ourselves down with excessive ABIs. > Maybe some core part can be put in stone but I think things like > internal workqueue implementation should be changeable without > worrying about ABI issues. That's most definitely so! There is and will be zero back-coupling from workqueue tracepoints to workqueue internals. Dont worry about this. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
