Re: [patch 06/16] Markers auto enable tracepoints (new API : trace_mark_tp())

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

On Tue, Nov 25, 2008 at 09:23:57PM +0900, KOSAKI Motohiro wrote:
> Sorry for very late response.
> However, if you do marker removing discussion, I hope CC to Frank Eigler.

Thanks!

> because SystemTap also use marker and tracepoint.  and this patch
> also improvement SystemTap marker support, I think.

I believe that this trace_mark_tp variant would operate at a level
below systemtap's.  It would mainly improve the kernel performance and
simplify kernel code.

> IIRC, Currently, Systemtap also have marker/tracepoint on/off
> synchronization problem.

Right, to the extent that systemtap can currently connect to markers
and not yet tracepoints, so tracepoints need to be converted to
markers or another systemtap-visible hooking mechanism at some point.
This is a temporary state of affairs though, as we hope to talk to
tracepoints directly before too long.


mingo wrote:

> > I was actually hoping for markers (the in-kernel API) to go away 
> > completely - and be replaced with tracepoints.

(If you're seriously contemplating outright removal of this API, then
the earlier worries about how markers would somehow tie its users'
hands to keep them around forever was surely exaggerated.)


> > Markers are the wrong design on several levels. They couple the kernel 
> > dynamically with unknown (to the kernel) entities -  [...]
> > Tracepoints are much more specific - typed and enumerated function 
> > call callback points in essence [...]

You are confusing type safety and "unknown (to the kernel)"-ness.

Markers provide some type safety via the format string; tracepoints
via individual C declarations.

Markers can connect to "unknown (to the kernel)" clients since their
API is EXPORT_SYMBOL_GPL'd.  Tracepoints do exactly the same thing.

There are certainly differences between them, but these two particular
ones are immaterial.


- FChE