* Peter Zijlstra (peterz@infradead.org) wrote:Maybe we could settle for an intermediate solution : I agree with you that defining the trace points in headers, like you did for the scheduler, makes the code much cleaner and makes things much easier to maintain afterward. However, having the trace_mark mechanism underneath helps a lot in plugging a generic tracer (actually, if we can settle the marker issue, I've got a kernel tracer, LTTng, that I've been waiting for quite a while to push to mainline that I would like to post someday). So I would be in favor of requiring tracing statements to be described in static inline functions, in header files, that could preferably call trace_mark() and optionally also call other in-kernel tracers directly. Ideally, we could re-use the immediate values infrastructure to control activation of these trace points with minimal impact on the system. One of my goal is to provide a mechanism that can feed both non-debug and debug information to a generic tracing mechanism to allow system-wide analysis of the kernel, both for production system and kernel debugging. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Eric W. Biederman | Remaining straight forward kthread API conversions... |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
git: | |
