dtrace discuss - Sep 2007 - DTraceTools Update

Is there any work on keeping DTraceTools up to date with the latest snv builds.
These  scripts are pretty useful and help get a novice dtrace user like me doing
useful work quickly.

Specifically the tcp stack tools like tcptop and tcpsnoop don''t work
with later OpenSolaris builds.

Thanks,
Gary


--
This message posted from opensolaris.org

Gary -

Though I''m sure Brendan will reply at some point, I''m sitting
at my
desk, at 21:16, Sunday night, and seem to have nothing better to do...

sigh...

So -

I don''t think anyone in particular had any plans to make updates on a 
per-build or change basis. It would result in fat and ugly scripts with 
lots if THIS VERSION then do something than if it''s this OTHER VERSION 
etc...

I would hope that if the scripts break for S10 that someone might take a 
look, but for changes in Nevada, I think you are going to have to wait 
until the Network Provider gets a look in...

If you search this alias, you should be able to see many posts by 
Brendan about why it''s so hard to write scripts on the FBT provider,
and
why they really want to get a stable provider in place to make all this 
stuff heaps easier...

I know this does not help... Maybe if you are feeling *really* lucky, 
and Brendan has had lots and lots of caffeine, you might be able to kid 
him into taking a look at them...

I suspect it would take a lot of coffee though... :)

Cheers!

Nathan.

Gary Gendel wrote:
> Is there any work on keeping DTraceTools up to date with the latest snv
builds. These  scripts are pretty useful and help get a novice dtrace user like
me doing useful work quickly.
> 
> Specifically the tcp stack tools like tcptop and tcpsnoop don''t
work with later OpenSolaris builds.
> 
> Thanks,
> Gary
> 
> 
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Nathan,

Thanks for the information. I suspected as much when I searched out postings
prior to asking. I guess the best thing is to hope for a stable API so this
issue will disappear. It wouldn''t be fair to ask Brendan to keep up
with an unstable API.

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.

Gary
> Gary -
> 
> Though I''m sure Brendan will reply at some point, I''m
> sitting at my 
> desk, at 21:16, Sunday night, and seem to have
> nothing better to do...
> 
> sigh...
> 
> So -
> 
> I don''t think anyone in particular had any plans to
> make updates on a 
> per-build or change basis. It would result in fat and
> ugly scripts with 
> lots if THIS VERSION then do something than if it''s
> this OTHER VERSION 
> etc...
> 
> I would hope that if the scripts break for S10 that
> someone might take a 
> look, but for changes in Nevada, I think you are
> going to have to wait 
> until the Network Provider gets a look in...
> 
> If you search this alias, you should be able to see
> many posts by 
> Brendan about why it''s so hard to write scripts on
> the FBT provider, and 
> why they really want to get a stable provider in
> place to make all this 
> stuff heaps easier...
> 
> I know this does not help... Maybe if you are feeling
> *really* lucky, 
> and Brendan has had lots and lots of caffeine, you
> might be able to kid 
> him into taking a look at them...
> 
> I suspect it would take a lot of coffee though... :)
> 
> Cheers!
> 
> Nathan.
> 
> Gary Gendel wrote:
> > Is there any work on keeping DTraceTools up to date
> with the latest snv builds. These  scripts are pretty
> useful and help get a novice dtrace user like me
> doing useful work quickly.
> > 
> > Specifically the tcp stack tools like tcptop and
> tcpsnoop don''t work with later OpenSolaris builds.
> > 
> > Thanks,
> > Gary
> > 
> > 
> > --
> > This message posted from opensolaris.org
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
This message posted from opensolaris.org

Hey Gary,

I am responsible testing all DTT scripts. We have tested all scripts against S10
and Nevada, of course there might be some issues introduced by certain updates
of Solaris and some scripts would not work (those scripts will need to be
fixed). We will try to fix these issues before reaching you.

I think the next version, 1.0 will be released later on, Brendan will give more
info when he is available. The plan was to have more scripts integrated in ver
1.0:

 - Java scripts
 - Python, Perl, Ruby
 - Webserver: SunJavaSystem Webserver, Apache 

and more documentation. All of these requires a bit more work and testing. 

Cheers,
Stefan


--
This message posted from opensolaris.org

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]

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: dtrace-discuss-bounces at opensolaris.org
[mailto:dtrace-discuss-bounces at opensolaris.org] On Behalf Of Brendan Gregg -
Sun Microsystems
Sent: Wednesday, September 05, 2007 6:04 PM
To: Gary Gendel
Cc: dtrace-discuss at opensolaris.org
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
dtrace-discuss at opensolaris.org

G''Day,

On Wed, Sep 05, 2007 at 08:07:25PM -0700, Fletcher Cocquyt
wrote:
> Re: not enough test servers
> Can''t Dtrace testing and development be done on virtual machines?
To an extent, yes (Rich Lowe just suggested it to me too :).

I can''t immediately think of a case where a stable provider probe would
differ on a virtual machine. The fbt-based tcp scripts, however, are
tracing code paths that depend on network device features (TCP LSO, for
example), and would be hard to test properly without actual hardware.
So other than some edge cases, virtual machines may fill in some OS gaps
for my development needs.
> 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 haven''t been using VMware since I haven''t seen a version
that runs on
Solaris as the host OS, and I only have Solaris at home...

Stefan Parvu does final testing of all the scripts - he might be able to get
milage from VMware running Solaris sooner than I can..

Brendan

-- 
Brendan
[CA, USA]

Brendan -

Xen might be another answer to this issue. :)

I''m using Xen now, as a Solaris Dom0 and have multiple (either HVM and 
or Paravirtualized) Solarii running on that box. (Also windows *shudder* 
and Ubuntu)

Again - Does not help for the specific hardware cases, but might be an 
answer to the Soalris only conundrum. ;)

http://www.opensolaris.org/os/community/xen/

Lemme know if I can help with anything in particular. ;)

Cheers!

Nathan.

Brendan Gregg - Sun Microsystems wrote:
> G''Day,
> 
> On Wed, Sep 05, 2007 at 08:07:25PM -0700, Fletcher Cocquyt wrote:
>> Re: not enough test servers
>> Can''t Dtrace testing and development be done on virtual
machines?
> 
> To an extent, yes (Rich Lowe just suggested it to me too :).
> 
> I can''t immediately think of a case where a stable provider probe
would
> differ on a virtual machine. The fbt-based tcp scripts, however, are
> tracing code paths that depend on network device features (TCP LSO, for
> example), and would be hard to test properly without actual hardware.
> So other than some edge cases, virtual machines may fill in some OS gaps
> for my development needs.
> 
>> 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 haven''t been using VMware since I haven''t seen a
version that runs on
> Solaris as the host OS, and I only have Solaris at home...
> 
> Stefan Parvu does final testing of all the scripts - he might be able to
get
> milage from VMware running Solaris sooner than I can..
> 
> Brendan
>

At the rate the world is going VM - the relevance of dtrace (code & kernel
&
(where does the hypervisor fit?)) could be considered in jeopardy of being
marginalized.
The way to combat this is to come up with a coherent strategy - adapt - test
against those tools - incorporate the hypervisors

BTW, I am a compsci grad educated on Sun HW and OS, but I make choices
according to best of breed philosophies (to the extent they are relevant to
best solving my problems this budget year and in years to come)

It seems to me the already accomplished value of Dtrace could be appreciated
by incorporating the VM - but that''s just my perspective (and hope) -
as one
who has bought into the VM message.
 



-----Original Message-----
From: Brendan Gregg - Sun Microsystems [mailto:brendan at sun.com] 
Sent: Wednesday, September 05, 2007 8:29 PM
To: Fletcher Cocquyt
Cc: dtrace-discuss at opensolaris.org
Subject: Re: [dtrace-discuss] DTraceTools Update

G''Day,

On Wed, Sep 05, 2007 at 08:07:25PM -0700, Fletcher Cocquyt
wrote:
> Re: not enough test servers
> Can''t Dtrace testing and development be done on virtual machines?
To an extent, yes (Rich Lowe just suggested it to me too :).

I can''t immediately think of a case where a stable provider probe would
differ on a virtual machine. The fbt-based tcp scripts, however, are
tracing code paths that depend on network device features (TCP LSO, for
example), and would be hard to test properly without actual hardware.
So other than some edge cases, virtual machines may fill in some OS gaps
for my development needs.
> 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 haven''t been using VMware since I haven''t seen a version
that runs on
Solaris as the host OS, and I only have Solaris at home...

Stefan Parvu does final testing of all the scripts - he might be able to get
milage from VMware running Solaris sooner than I can..

Brendan

-- 
Brendan
[CA, USA]