> - analysis looks a little cryptic and crowded. If you allocate more
> vertical space per process, you can stack information vertically,
> avoiding overlaps.
I fully agree.
> - the information available should really be similar to what strace
> has. If your process is always just reading messages, then sending
> a few, you really want to know what's inside of them. Manually
> combining trace information obtained from multiple sources is tricky
> and error-prone.
This is interesting. I agree, but the problem is that the way LTT logs
system calls is different than the way strace gets it's information.
Nonetheless, I intend to provide a way to configure the kernel trace
module in order to get more information about what the kernel does. The
content of some system calls could be one of the configurable options.
> - I like the idea of tracing bottom half handlers; now it should also
> trace interrupts
I must disagree to some extent here. I thought a lot before deciding not
to trace interrupts. The reason is that interrupts under linux often are
short and only take care of some hardware issues before setting a bottom
half and "exiting". Therefore, the "important" stuff only happens in the
bottom half. Moreover, when logging a certain event, the kernel trace
module uses spin locks ... I am not sure that it is safe to use spin locks
inside interrupts. No?
> - you should be able to turn off part or all of the traceing at
> compile time, such that you can use the same source tree for normal
> kernels.
Agree. This one has been on my list for a long time.
> - there should be a means for user processes to explicitly add data to
> the trace (this can be trivial, without any extra system calls or
> such: create a symlink /dev/tracer -> /dev/null; let process open it
> and write user data to it; in trace analysis, you catch "/dev/tracer"
> and label it as user data)
I hadn't thought of this one ... even though I knew I wanted to provide a
way for user processes to provide more tracing information. This is a good
way to to it.
>
> I haven't looked at it in detail, but do you also have text output ?
> Sometimes you really want to run a few scripts over traces before they
> become even remotely useful ...
The graphic tool can also be used to generate text output. Give it the
right flags and it will filter what you want. You can choose to view
trace information about only once process or only certain types of
events, etc.
>
> Looks like a nice tool with a lot of potential.
Thanks again for your feedback and don't hesitate to send more ...
==============================================
Karim Yaghmour
karym@info.polymtl.ca
Computer Engineer
Ecole Polytechnique de Montreal
==============================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/