Dtrace: D is not C. Repeat after me.

I'm getting a little frustrated with Dtrace. I feel I understand
a lot about it, but the fact that it looks like C doesnt mean it
bears any resemblance to C. At all. No!

Heres some issues:

1. No support for "if". Everything must be using the ?: construct.


2. No loops. Ok, we understand that - because we are running in
   kernel context. But we could allow time limits of instruction execution
   limits to avoid long execution times.


3. No functions. No macros. (You can use the C preprocessor but thats
   optional, and not a part of the default/core language). Functions are
   nice - they let you break up long complex scripts, and avoid
   repetition. But we can't.


4. No #include. Well, we can have it if we use the C preprocessor.


5. No "struct" or "typedef" inheritance from /usr/lib/dtrace

This last one is strange. dtrace reads the files in /usr/lib/dtrace "in a
strange way" to hide and augment implementation scenarios.

With SDT in Linux, but no CTF support (kernel data structures), we
can achieve a goal of ensuring base types and structures are
usual in D scripts, by creating public struct/union/typedefs. These
are needed for static probes and the "translators" which map from
internal C format to D format, in a safe way.

But we can't put struct/union/typedef in a "*.d" file in /usr/lib/dtrace,
because although dtrace reads these files, it discards the structs.

Most D scripts dont explicitly "#include" - but dtrace arranges
things so it knows the type of args[0], args[1], ... for the probe.

So, as of today, I have io:::start and io:::done working, but only
if I code the struct/translator into the calling script. Thats not
how Apple/Solaris work.

What gets me is the "surprise" factor - I'll work out a solution
that makes this seemless, but its annoying to bump into a "it doesnt
work that way!" scenario.



Post created by CRiSP v10.0.2a-b5886