--- Horst von Brand <[EMAIL PROTECTED]> wrote: > If it can't find out where a function could be called through a pointer > (very common due to the OOP-in-C style in the kernel) it has no chance.
Dear Horst, No chance of what? You do raise an interesting point. Linux-tracecalls already does "find out where a function could be called through a pointer" internally. Therefore, it would be trivial to add some indication to the the head of the call chain that the subsearch aborted because a callback was detected; and I shall do so in the next release of the tool (which will shortly after kernel.org kernel 2.6.11 is released). The fact that the tool at this stage of development does not do something that it was never designed to do, does not make it worthless. Moreover, I believe the burden of your comments to be ill-considered for the following reasons: The functions you refer to are the callbacks that I have explicitly referred to at http://www.linuxrd.com/~carl/linux-tracecalls : Also, by design, 'linux-tracecalls' will stop tracing when it reaches a syscall, a gcc-builtin function or a callback. I should have further pointed out, were it not so obvious, that if the call chain as produced by the tool begins with function F (ie 'F' is the oldest ancestor of the initial target function) then: 1) You have been saved all the work of doing the tracing manually to that point, not only for that particular chain but for all the chains leading to your initial target function. 2) You can then manually check at function F to see if there is a callback behind it. 3) If you find there is a callback behind F then you can do another query using the actual function represented by the callback as a new initial target. 4) Callbacks - due to the OOP implications you have pointed out - are in most cases ultimately invoked due to syscalls and the core part of the kernel generally (drivers do use OOP of course but it is not the absolute necessity there it is in the case of, for example, the VFS). That being so the paths to the callbacks are generally short ; thus the tool is doing most of the work for you in any case, even in the minority of cases involving a callback. 5) The tool has also done all the macro expansions of function-yielding macros for you, which due to the recursive nature of kernel header files is a major job in itself. At some future date I would like to add the capabilities you suggest - however 'lnxtc.pl' is presently over 800 lines of code and what you are suggesting is at least an order of magnitude harder than what has been accomplished already, so it won't be next week If this tool is really as useless as you suggest then I shall discontinue development. But I strongly disagree. NIH? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
