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

[Mathieu Desnoyers]

* Linus Torvalds (torvalds@xxxxxxxxxxxxxxxxxxxx) wrote:
> 
> 
> On Tue, 30 Oct 2007, Mathieu Desnoyers wrote:
> >
> > * Jeff Garzik (jeff@xxxxxxxxxx) wrote:
> > ...
> > > Pick a shorter word like probes or profile or what... or better yet... 
> > > just leave most things in their current directories.
> > ...
> > 
> > 
> > How about something along the
> > 
> > kinst or ki
> > 
> > lines ?
> > 
> > (for "kernel instrumentation")
> 
> No, that's horrible.
> 
> Also, in general, why do people want to have an "instrumentation" thing? 
> Yes, you can put random things into the same box, but that doesn't make 
> them be the same thing. Personally, I don't think "instrumentation" is 
> very useful at all. I consider "profiling" and "markers" to be two 
> fundamentally different things, and putting them both in the same box does 
> not make them any more similar. 
> 
> Yes, technically they are both "instrumentation", but hey, technically the 
> VM and the VFS layer are both "infrastructure", but we don't put *those* 
> in a "infrastructure" subdirectory.
> 

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.

> In other words, the fact that two different things share some attribute 
> does not mean that they should be collapsed together by that attribute, 
> does it?

It becomes interesting when they can share code and/or a common control
architecture. The fact that markup could be shared between profiling and
tracing could be a good incentive to do so.

> 
> I think "instrumentation" was/is a particularly bad thing to group things 
> by. It doesn't actually tell you anything about the thing, and it's not 
> even true that some people are interested in "instrumentation"  and others 
> aren't. 
> 

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


> For example: I think profiling support is something REALLY FUNDAMENTAL. 
> It's something each and every developer should generally care about, and 
> OProfile should be considered an indispensable tool for any developer, on 
> par with something like gdb.
> 
> In contrast, we should *not* expect most people to do any kernel markers 
> etc. That's a very esoteric thing.
> 

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. Sadly, the blame is often put on kernel developers because
tools like gdb, oprofile and strace are practically useless to solve
such problems and people lack the right tool for the job.

Therefore, marking up the code to perform tracing should not be
considered esoteric: it's a very useful tool when one needs to
understand what is happening in their large scale system. Userspace
doesn't always have the ability to isolate problems and, worse, some
problems a just unreproduceable when tried to be isolated. I think it is
sensible to give them a tool that helps them understanding what is going
on.


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

Regards,

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/