On Wed, 2008-07-23 at 11:08 +0300, Avi Kivity wrote: > Peter Zijlstra wrote: > > On Tue, 2008-07-22 at 21:46 +0300, Avi Kivity wrote: > > > >> Jan Kiszka wrote: > >> > >>> That's true - as long as you don't have to add/remove/modify > >>> tracepoints. I had to do this job in the past (not for KVM). Having 1 > >>> spot in 1 file (based on generic probes) would be handier in that case > >>> than 5 spots in 3 files. But if the KVM tracepoints are considered > >>> stable in their number and structure, that shouldn't be an issue here. > >>> > >>> > >>> > >> Tracepoints aren't stable; they are artefacts of the implementation. > >> > > > > Which IMHO makes it unsuitable for trace_mark() as that will be exported > > to user-space, and every time you change your tracepoints you'll change > > user visible things - not nice. > > > > They are used for debugging (mostly performance related), so changes are > expected. > > What uses of trace_mark() depend on a stable interface? blktrace?
There are currently no trace_mark() sites in the kernel that I'm aware of (except for the scheduler :-/, and those should be converted to tracepoints ASAP). Andrew raised the whole point about trace_mark() generating an user-visible interface and thus it should be stable, and I agree with that. What that means is that trace_mark() can only be used for really stable points. This in turn means we might as well use trace points. Which allows for the conclusion that trace_mark() is not needed and could be removed from the kernel. However - it might be handy for ad-hoc debugging purposes that never see the light of day (linus' git tree in this case). So on those grounds one could argue against removing trace_mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html