Messages in this thread | | | From | David Sharp <> | Date | Thu, 7 Jul 2011 15:50:04 -0700 | Subject | Re: [PATCH v2] trace: Add x86 irq vector entry/exit tracepoints |
| |
On Thu, Jul 7, 2011 at 2:57 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * H. Peter Anvin <hpa@zytor.com> wrote: > >> Yes, it was much more of a generic concern. However, it is very >> important that people have a correct idea about what the stability >> of something like tracepoint is -- or we'll end up in a situation >> where we can never change the kernel because anything is suddenly >> "user space visible." > > We've transitioned even ABI-assuming tracepoints in the past, so it's > not a big issue in practice. The reason is that this is an atypical > type of ABI: information is read-only exported, for observation > purposes. > > If the kernel changes in a fundamental way that removes a tracepoint > altogether, then there's nothing left to observe - so apps don't > break per se. > > So i've yet to see a single example of the kernel 'never being able > to change' due to a tracepoint. The worst we've seen in practice is > the inability to change a specific tracepoint (not the surrounding > kernel code - while preserving the information that is exposed) - so > the worst effect was limited to tracing itself - never to the > subsystem that it traces. > > Note that even in that (single known) example we were able to resolve > the problem (which was limited to the tracing subsystem) by adding > new tracepoints and thus phasing out the old ones. > > Thanks, > > Ingo >
Thanks all for your thorough review. :) It sounds like there is some agreement now. I think this Steve is waiting for an Acked-by from an x86 maintainer to apply this patch. Are there any further objections or comments on the patch?
d# -- 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/
| |