Re: [RFC][PATCH 1/2] tracing/ftrace: syscall tracing infrastructure

[Frederic Weisbecker]

On Sat, Mar 07, 2009 at 05:52:59AM +0100, Frederic Weisbecker wrote:
> The most important drawback that implies the syscall tracing is the variable
> number of parameters that takes a syscall. Assuming there is a large number of
> syscall, the goal is to provide as much as possible a generic layer on it.
> 
> What we want on tracing time (the hot path):
> 
> - Save the parameters and the number of the syscall. That's all. The rest of the
>   job can be done on the "output path".
> 
> On output time:
> 
> - Get the raw-binary saved parameters and the syscall number as well as some
>   usual infos such as the pid, the time...
> - Depending on the tracing requirements, the user should have the choice to
>   dump the raw datas or a formatted version.
> 
> The core infrastructure has a static array which contains the necessary
> informations for each syscall (ok, I've only implemented 4 for now).
> 
> When a syscall triggers, the tracer look at this array (O(1) access) and get the
> number of parameters for this syscall. Then these parameters are saved in a
> binary form on the ring buffer with the syscall number (a generic version, arch
> independent).
> 
> On output time the parameters, the name of the syscall and very basic
> informations to format the parameters are picket from the ring-buffer and the
> generic syscall array.
> 
> Depending of the level of implementation we want for the syscall inside this
> array, we can provide just a single mask where the n bit matches the n
> parameter. If the bit is set, then the parameter will be considered as a string
> pointer. Otherwise its raw hexadecimal value will be printed.
> 
> If needed, we can otherwise provide a specific callback to print the syscall
> event.
> 
> The probem with these approaches comes from the fact that the string might have
> disappeared from the user memory on output time. Even if we protect against
> faults, it can give unreliable traces.
> So perhaps we could think about copying the string on tracing time.
> 
> Concerning the return value, it doesn't make any problem, a single raw
> value is printed for each one.
> 
> Note that the current implementation can be easily scaled further to give only
> binary informations to the user and the matching metadata to decode it.
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> ---


I made some silly mistakes on this one.
Here is a v2:

---