One thing I suspect people may be forgetting in the race to emulate YA
feechure of YA UNIX variant is that
one of the reasons for DTrace's complexities (hierarchical namespace,
in-kernel interpreter)
is the complexity of the Solaris kernel.
When they're trying to work out how a thread in a proc in a zone in an
ldom got to spin on a lock,
you *need* awk in your kernel to work out wtf is going on.
(In fact, for the serious cases, to me,
D feels too limited to be useful because of it's deliberate
restrictions,
yet too dangerous due to its possible unbounded runtime
).
In reality, for many cases, something simpler does the job better:
other people use DTrace to do what I would do with truss(1) and a few
joined-up braincells.
The latter uses less time and effort and doesn't Heisenberging your
kernel nearly so much.
On plan9 this is even more the case.
I'd be happy to see a BPF-style filter in the kernel for filtering
events before chucking them up to userland,
but a language interpreter and all the associated mess, overheads and
potential security holes?
No thanks.
D
On 8 Nov 2009, at 14:19, dav...@mac.com wrote:
I don't know anything specific about DTrace,
<insert-obvious-and-boring-sarcastic-comment-here/>
but I'm thinking a clear,
consistent interface for logging and tracing kernel operations sounds
like a good thing.
So am I, but how does this relate to dtrace?
D
