> > The system call tracking is only used to associate a particular EIP with
> > a particular offset in some binary image. There's no other efficient
> > method to capture the mmap() calls for these images, for everything
> > running. ptrace() is only really useful for a small number of processes,
> > and is slow. Offline post-analysis isn't possible. There is no
> > API for getting access to this information.
>
> Ok, so you have a real reason for dealing with it
pice (another kernel debugger) needs it also, it's not only oprofile.
I think it is a bad idea to remove it. It just means that these programs
will access it via System.map instead of an exported symbol. It doesn't change
anything, just makes life harder for some people.
> Lets see if we can sort out AFS and the like then come back to that one. I
> think you may have a valid point. If 2.5 has EXPORT_SYMBOL_INTERNAL it
> gets a lot easier.
That doesn't help the oprofile users who want to use it in 2.4 now.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/