Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [patch 06/16] Markers auto enable tracepoints (new API : trace_mark_tp()) | Date | Tue, 25 Nov 2008 21:23:57 +0900 (JST) |
| |
Hi
Sorry for very late responce. However, if you do marker removing disucussion, I hope CC to Frank Eigler. because SystemTap also use marker and tracepoint. and this patch also improvement SystemTap marker support, I think.
IIRC, Currently, Systemtap also have marker/tracepoint on/off syncronization problem.
> > Add a new API trace_mark_tp(), which declares a marker within a > > tracepoint probe. When the marker is activated, the tracepoint is > > automatically enabled. > > > > No branch test is used at the marker site, because it would be a > > duplicate of the branch already present in the tracepoint. > > > > Impact: new API. > > i dont know. > > I was actually hoping for markers (the in-kernel API) to go away > completely - and be replaced with tracepoints. > > Markers are the wrong design on several levels. They couple the kernel > dynamically with unknown (to the kernel) entities - and that is > causing complexity all around the place, clearly expressed in these > patches of yours. > > Tracepoints are much more specific - typed and enumerated function > call callback points in essence - with some politeness that allows > external instrumentation entities to attach to those callbacks. > > Is there any usecase of markers that should not be converted to either > tracepoints or to ftrace_printk() ?
Frank, Could you please read this thread and give us your comment?
| |