Re: not enough test servers Can't Dtrace testing and development be done on virtual machines? Doesn't Dtrace behave the same on a Solaris 10 virtual machine (eg VMWare's free server?) - and yes as far as I know there is not currently a way to create a Sparc VM, but x86 based OSes are well represented. I'm keen to test out VMWare Lab Manager which purports to be the solution for rapid deployment of whole sets of test system Thanks for continuing the development DTrace
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Gregg - Sun Microsystems Sent: Wednesday, September 05, 2007 6:04 PM To: Gary Gendel Cc: [email protected] Subject: Re: [dtrace-discuss] DTraceTools Update G'Day Folks, Plans to update the DTraceTools (DTraceToolkit)? yes. Development has been happening, but I haven't wanted to upload a new version without addressing the tcp* scripts first. somehow. They have exposed an issue with versioning of unstable scripts and supported OSes, which I'll use this thread to discuss at some length for anyone interested. ... Firstly, most of the DTraceToolkit *is* up to date with the latest snv builds, since most of the DTraceToolkit uses stable DTrace providers (as it should). Some stable providers are not yet available, and until then we are in an awkward place -- people on older (and newer) builds may find some of the fbt based script don't work. I'm currently thinking that it would be practical to only support the following, Solaris 10 3/05 OpenSolaris latest build MacOS X Leopard [insert OSes here after DTrace is ported] I've already made changes to the man pages to show which operating systems each script will run on. This means that the tcp* scripts need updating to support the latest OpenSolaris builds (and updating, and updating, as things keep changing). Of course, life will be somewhat easier when stable networking providers exist, and the tcp* scripts can use their probes (although, I'm expecting tcpsnoop and tcptop to need more than just the network providers to become "stable"). Several people have asked about the tcp* scripts on Solaris 10 6/06 and other Solaris builds (builds inbetween 3/05 and the latest OpenSolaris). I've wanted to have a go at fixing these scripts for these minor releases - but since moving to the US I've found it harder to re-acquire a pile of test servers to support them (SPARC and x86 servers for every Solaris 10 release == a lot of servers, space and electricity). The desire is there, but the servers are not; not to mention that it will probably eat up a lot of my spare time to port these. Now, if I or someone else do eventually port the tcp* scripts, that then presents a versioning issue in the DTraceToolkit, and I'd prefer not to have fat ugly scripts in a "THIS VERSION", "THAT VERSION" style as Nathan has mentioned. I'm thiking the way ahead would be a "Versions" directory with entire ported copies of the script. eg, /opt/DTT# ls -1 Net/tcp* Net/Versions/tcp* Net/tcpsnoop Net/tcpsnoop.d Net/tcpstat.d Net/tcptop Net/tcpwdist.d Net/Versions/tcpsnoop.sol10u2.d Net/Versions/tcpsnoop.sol10u3.d Net/Versions/tcpsnoop.sol10u3 Net/Versions/tcptop.sol10u3 Remember, there won't be many scripts in these "Versions" directories, just those *fbt* based scripts that have broken, so it won't be that common to need to poke around there. However, what happens if I have a *stable* provider based script, and want to enhance it to use newer DTrace features (like multiple aggregations)? I would end up with two or more versions, one for Solaris 10 3/05 (without the enhancements), one for the latest OpenSolaris (with the enhancements), and possibly another for MacOS X (with whatever they support so far), and maybe another for Linux (when they port DTrace :-). Would some of these get moved to the "Versions" directory (forcing people to frequently look in there)? Do I write a wrapper for every script, isaexec style? Do I deal with it in the installer script, symlinking the correct version based on your OS? Do I have ugly ifdef THIS VERSION statements throughout the scripts?... I don't know what to do yet, but it won't be long before I'll need an answer (I do want to start using some of the new DTrace features, as well as supporting those on Solaris 10 3/05). Ideas? Until I know of a sensible way to do it, I could add scripts with an "x" after their name - for "extended" (and rename them when we think of something better). Eg, hotuser # Solaris 10 3/05 (uses ustack() + perl) hotuserx # Latest OpenSolaris (uses ufunc() and umod()) hotuser would be the most glaring example, since the code will become trivial if I can use ufunc() and umod() instead. I don't know which version MacOS X would run (need to check if it has ufunc() and umod())... I should stress that this issue is only for scripts where using new DTrace features is *really* desirable -- I'll still prefer to write for Solaris 10 3/05, since those scripts will probably work everywhere (MacOS X, etc). On Sun, Sep 02, 2007 at 05:58:54AM -0700, Gary Gendel wrote: [...] > However, since it isn't a stable API, maybe the second best thing is to ask for much more detailed description of the tcp dtrace scripts and what they're expecting from the current hooks. Then it may become easier for people trying to come up the learning curve to feel comfortable about hacking the scripts for the current Nevada API. You can just read the tcp scripts to see what they are reading; however this comes with a warning -- I've spent a lot of time in the TCP/IP stack since writing them, and given a second chance I'd rewrite them in a different (meaning better) way. Rather than explaining how they work, it would be probably be best for me to rewrite them to show how they should have worked. (I should add that I started writing them before I had access to the Solaris source code - which made it hard to figure out what best to do). As for becoming comfortable about hacking scripts -- analysing TCP/IP from the fbt provider is a bad place for learning DTrace, as you'll quickly become buried in kernel source (try following both an inbound and outbound packet through every line of code between the network driver and the application syscalls). It requires much knowledge and testing to write accurate scripts. If you are up for a challenge - go for it!, or, wait for stable network providers. Brendan -- Brendan [CA, USA] _______________________________________________ dtrace-discuss mailing list [email protected] _______________________________________________ dtrace-discuss mailing list [email protected]
