lkml.org 
[lkml]   [2004]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: LTT user input
On Fri, 23 Jul 2004 15:44:19 -0500, zanussi@us.ibm.com wrote:
> I didn't know the auditing framework was a tracing framework. It
> certainly doesn't seem light-weight enough for real system tracing,
> which was the question. Are there other frameworks we should consider
> tracing on top of?

I haven't looked at any of these frameworks closely enough to answer
that. My comments were largely based on the observation that there are
several interesting projects that instrument the kernel (typically system
calls) to log information: auditing, performance, or something else.

All of them seem useful, but we can't keep adding hooks for each purpose.
It's like what we had before LSM (in a different area).

> > What is important to me is irrelevant. Both Linus and Andrew have stated
> > that demonstrated usefulness for many people is one key criteria for
> > merging new stuff.
>
> And where was the 'demonstrated usefulness for many people' of the
> auditing framework?

Well, it's _one_ key criteria. I suspect in this case the decisive
factor was rather the desire to please certain institutions that won't
consider an OS if it can't spy on its users <g>. But I'm making this up,
I'm sure someone remembers the real answer.

Quite frankly, I couldn't care less about auditing. I am much more
interested in tools that help me track down problems. Dprobes and LTT
do look promising. Then again, so did devfs.

> > That's your problem right there. Nobody cares if LTT is happy. It is
> > people who matter. LTT users.
>
> Right, so LTT is the only potential user of the framework that would
> care about performance. I guess we and anyone else who does can't use
> it then.

No reason to be sarcastic. I didn't say nobody uses it. But those users
aren't exactly highly visible, either.

If you want a textbook example of how to spectacularly fail on this
very issue, recall the LKCD flame war (a couple of years ago?).

> Well, this is what DTrace does too and in almost exactly the same way,
> using an in-kernel interpreter similar to a stripped-down JVM where
> nothing malicious can get out and alter the system. It's basically
> where all the 'magic' of DTrace happens. I know, trying to get
> something like this into mainline would be a hard sell, but if you
> know of anything less scary that would let us do thing as exciting as
> DTrace does, let me know...

Heh, that's your job :-). Given that a Java/FORTH/whatever interpreter
is unlikely to be merged into mainline anytime soon, what excitement
can we still offer with the complex stuff living in user space?

Even if your goal is to beat DTrace eventually, you need to sell patches
on their own merits, not based on what we could do in some unlikely or
distant future. DTrace is a red herring, more interesting is what we
can do with, say, basic LTT infrastructure, or dprobes, etc.

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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.084 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site