Re: [RFC] Create kinst/ or ki/ directory ?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 30 Oct 2007, Mathieu Desnoyers wrote:
> 
> The key idea for collapsing profiling, markup and tracing was that
> marking up the code is required for both profiling and tracing. It's
> only the code that is called from that markup site that differs.

What code is actually shared? 

Regardless, an internal implementation issue is *not* a good basis for a 
user-visible interface. 

> Ok, so maybe we should keep "markup", "tracing" and "profiling"
> separately and see how things evolve.

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.

> With SMP systems becoming cheap commodity hardware, each and every
> developer increasingly face thorny race problems, both in user-space
> apps and in the kernel, which may involve hypervisor-kernel-userspace
> interaction.

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)

> > So I actually think that the current Kconfig.instrumentation should be 
> > *removed*. Rather than adding more groupings based on that 
> > fundamentally flawed premise of false commonality.
> 
> Should it come with a re-duplication of it's content into each 
> architecture, which was the case previously ? The oprofile and kprobes 
> menu entries were litteraly cut and pasted from one architecture to 
> another. Should we put its content in init/Kconfig then ?

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
-
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/