Hi!
I'm in the process of adding USDT probes to MySQL Proxy and am
experiencing some problems with my approach.
For example, I have one probe that fires when the state of a
connection changes (the state machine is based on the MySQL protocol):
(FYI, this is all done on OS X but everything is applicable to
OpenSolaris as well)
the provider .d file contains:
--------
provider mysql_proxy {
probe state__change(int, short, void *);
};
--------
In a source file I invoke the probe with:
MYSQL_PROXY_STATE_CHANGE(event_fd, events, con);
event_fd and events are int and short, respectively.
con actually is: network_mysqld_con *con;
Now the problems start: I meant to pass in high-level information into
the probe, because that will maximize the flexibility of writing
scripts.
But now writing a D script that makes use of con means either
- including the structs and enums in the script
- including the original header file and using that
- doing lots and lots of error prone copyin(arg2 + xxx,
sizeof(type)), which is neither elegant nor nice on the script author
Because 'typedef struct { ... } network_mysqld_con' is actually a non-
trivial struct and refers to various other structs and enums it's not
a good idea to copy it in. Things _will_ get out of sync.
Including the original header didn't work either, because that's
eventually pulling in system headers that define functions which break
the script compilation (I've seen this problem on both OS X and
OpenSolaris. E.g. OS X chokes on /usr/include/sys/_structs.h)
Which leaves me with option 3 and that's equally burdensome and
errorprone, especially given the multitude of structs I have to deal
with. Much of the flexibility about DTrace would be sacrificed if I
would pass in only a few specific members of the structs, too.
What is the current best-practice for this kind of situation? [1]
I have read about DTrace translators
(<http://blogs.sun.com/tdd/entry/example_of_a_dtrace_translator
>) but I think that's only available for DTrace >= 1.5, correct?
Apple's implementation seems to be 1.2.2, if I can believe its output.
Also, the translators seem to make it easier for the script writer,
but can't solve the underlying maintenance problem.
Essentially I'm coming to think that this calls for a simple tool that
takes struct definitions and produces suitable D code for prying them
apart again, without pulling in all of the headers involved. Then the
actual struct access could either be implemented using translators if
available or by using copyin(arg + offset, sizeof()). The entire thing
could futher be hidden behind macros, which could live in header files
shipped with the actual product. Those would be generated at build
time. Does that even remotely sound like a good idea?
Thanks,
-k
[1] I've seen
http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python-07-dtrace.diff#263
and http://prefetch.net/projects/apache_modtrace/scripts/
apachetop.pl as examples and both seem to go down a path I don't
really wanna tread... :(
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
_______________________________________________
dtrace-discuss mailing list
[email protected]
