Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers

[fche at redhat dot com (Frank Ch. Eigler)]

Steven Rostedt <rostedt@goodmis.org> writes:

> [...]  Format strings only help for printf like operations. [...]

That is not so.  They are far from panaceanic, but printf formats are
useful for type checked simple scalars, which we can extract and use
for purposes other than printf like operations.

> The best example of this is the sched_switch code. LTTng and friends
> just want a pid and comm to show. But there's tracers that want more
> info from the task_struct. We also like to see the priority of the
> task.  [...]

This is the sort of information that can help generate a compromise.
For this case, pass a few raw pointers that a compiled-in tracing
engine can dereference at will, and *also pass* a few user-level
scalars that a separately-compiled tracing engine can use.

> Passing in a pointer to the structure being traced should be enough
> for all tracers.

On the contrary, we have explained why *this is not so*.  Using raw
general structure pointers in impractical for some tracers.

> Now back to your question, why don't we like the printf
> format. Simply because it does nothing for pointers. It might help
> you with a %d and number of parameters, but a %p can not tell the
> difference between a struct tasks_struct *, and a int *, which can
> have even more devastating results.

Indeed.  Unfortunately, C is not kind to us in the way that perhaps
C++ templates could be.  We have not yet seen a single mechanism that
does all of:

- type-safe passing of arbitrary pointer/etc. types (so compiled-in
  trace data consumers can go wild with data passing)
- declarative / separately-compiled consumption of types
  (so lttng/systemtap/userspace can hook in without heroics)
- parsimonious implementation

Maybe a solution could involve some restrictions on the generalities.
For example, can we narrow down the number of different scalar +
pointer types to a fixed handful?  Can we tolerate type-safety being
provided by families of function declarations rather than one generic
one?


> It also just looks like a debug session instead of a trace marker.

Why do you think the difference between those is profound?


- FChE