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:
- No support for "if". Everything must be using the ?: construct.
- 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.
- 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.
- No #include. Well, we can have it if we use the C preprocessor.
- 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, args, ... 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.