Cc: Jeff Garzik <jeff@...>, Randy Dunlap <rdunlap@...>, <hch@...>, <linux-kernel@...>, Sam Ravnborg <sam@...>, Jens Axboe <jens.axboe@...>, Prasanna S Panchamukhi <prasanna@...>, Ananth N Mavinakayanahalli <ananth@...>, Anil S Keshavamurthy <anil.s.keshavamurthy@...>, David S. Miller <davem@...>, Ingo Molnar <mingo@...>, Peter Zijlstra <pzijlstr@...>, Philippe Elie <phil.el@...>, William L. Irwin <wli@...>, Arjan van de Ven <arjan@...>, Christoph Lameter <christoph@...>, <Valdis.Kletnieks@...>
What code is actually shared?
Regardless, an internal implementation issue is *not* a good basis for a
user-visible interface.
I think so. At least conceptually - ie it might be fine to share a Kconfig
file, but there probably shouldn't be some forced shared choice about it.
Well, the thing is, most of the time, those app developers will not be
doing kernel-level markers. But they may well be doing profiling.
Speaking as an application developer myself (git), I care deeply about
good profiling info, and I love Oprofile. But even though I'm a kernel
person too, I'd not want to do kprobes. It's just not relevant to me as a
user-land developer.
(I might want to extend on strace, but if so, I'd do it generically, not
as a "probe". For example, I'd love to see the page faults, but I think
they really *are* "system calls", so I think it would make more sense to
extend on the ptrace interface than to have any kprobes thing)
I don't think it's a good idea to go back to making it per-architecture,
although that extensive "depends on <list-of-archiectures-here>" might
indicate that there certainly is room for cleanup there.
And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
just think it's wrong to (a) lump the code together when it really doesn't
necessarily need to and (b) show it to users as some kind of choice that
is tied together (whether it then has common code or not).
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumentation.
It would be much better to do
depends on ARCH_SUPPORTS_KPROBES
in that generic file, and then architectures that do support it would just
have a
bool ARCH_SUPPORTS_KPROBES
default y
in *their* architecture files. That would seem to be much more logical,
and is readable both for arch maintainers *and* for people who have no
clue - and don't care - about which architecture is supposed to support
which interface...
Linus
-
