Just a note to say I am seeing an uptick in dtrace - which is good.
Unfortunately, some of the support issues are causing me to deeper dive
the issues, so, please bear with me if I am being unresponsive, or erratic
in responding or fixing.
I am trying to get dtrace enhanced in some areas - but also having
to revisit some of my ugly code or hacks - more a factor of the Linux
kernel evolving. What works for todays kernels may not be true for
older kernels, and its difficult trying to be careful not to break
old or new kernels. I dont like #ifdef spaghetti, but sometimes my
interpretation of the kernel evolution, is mistaken, and some code
rot creeps in.
Just as a minor update, I am adding a little more TCP provider support.
(Just added tcp::connect-established, for instance). More work is
done to mirror all the TCP probes, as documented here:
https://wikis.oracle.com/display/DTrace/tcp+Provider
and to eventually support the callback arguments.
Post created by CRiSP v11.0.10a-b6436
Paul, just a question about the documentation you expect people to use when using providers. You've got a link to some Oracle info there for the TCP provider. Are all the arguments and structures for the providers the same in Solaris and Linux? Why does that seem horribly unlikely to me? Are you implying that the tcpsinfo_t structure and all its contents are constructed the same way in both systems? I was just trying to use the IO provider for instance, and the start probe doesn't seem to support argv[1] as a devinfo_t, or argv[2] as fileinfo_t.
ReplyDeleteI'm currently using dtrace-20130117.
If you've got links to what you'd consider the best available documentation that describes the general differences in the implementations, and/or how completely the Linux implementation has been fleshed out, please point us to it. Thanks. Even though your port seems incomplete and undocumented, it's still outstanding stuff. Great work! Keep at it.