On Sun 05 Dec 2004 at 03:30PM, Bryan Cantrill wrote:> - Dan Price. On a quest to automate us out of our moonlighting job as > DTrace hucksters, Dan has developed a Java application that can be used > to easily show off the power of DTrace. Perhaps Dan can be pursuaded > to release this under CDDL?It''s already in the works, except to say that I haven''t yet gone through the "which license to use" part in any detail. One of the things I''m learning is that we (Sun) are still figuring out how to open source smaller works without incurring large amounts of (costly) process. I decided to test this process out, because we have a lot of "home directory" software in the kernel group (and in the wider inside-Sun Solaris Community) which we should be sharing with the wider community going forward. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
On Sun, 5 Dec 2004 15:30:40 -0800 (PST), Bryan Cantrill <bmc@zion.eng.sun.com> wrote:> But enough pleasantries -- what are the DTrace plans with respect to > OpenSolaris? For starters, we want to open all of our internal DTrace > content and make opensolaris.org the home for all DTrace content going > forward.Hey Bryan thanks for the excellent introduction. First of all I am overwhelmingly happy about opensolaris.org becoming the source for all dtrace development / content both internal and external. It is statements like this that keep my faith in the success of the opensolaris community.> - Make additions to the DTrace web pages on opensolaris.org. Because > opensolaris.org is a wiki, anyone can make additions to virtually any > page. Don''t hesitate to make additions or modifications where you see > fit!Can you clarify how this can be done? It is my understanding that a wiki was going to be set up but has not been done so yet. ... snip ....> > Let us know if you''re interested in any of the above, and we''ll work on > getting you (and everyone, for that matter) the details required to get > started.Personally I would be vary happy to contribute to the dtrace project once I finish a white paper I am currently writing on looking into solaris processes. Which leads me to a request. I would personally like to see a mailing list / project area like the dtrace area but for mdb / kernel and crash debugging. Is there a team in Sun similar to you guys that I could talk to about this ? Once again thanks for your welcome and openness. Shanon -- "We can debug relationships, but it''s always good policy to consider the people themselves to be features. People get annoyed when you try to debug them." Larry Wall _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
All,
A belated welcome to the DTrace list at opensolaris.org. Apologies for the
growing pains, including (but not limited to) the incorrect "From:"
line,
the strange address (as others have pointed out, "www" has no place in
an
e-mail address) and the fact that the DTrace team wasn''t actually on
the
list. (As it turns out, being an administrator of a list doesn''t mean
that
you''re automatically on it.) All of these problems have now been
rectified,
so please let us know if anything else seems amiss.
Presumably most (all?) of you know something about DTrace, and we would
suspect many (all?) of you have actually used DTrace. But if you
haven''t
heard of DTrace, check out the BigAdmin page:
http://www.sun.com/bigadmin/content/dtrace
And if you haven''t used DTrace, then you don''t know what
you''re missing;
snag the Solaris Express 11/04 and (as Jarod would say), "giddyup":
http://wwws.sun.com/software/solaris/solaris-express/get.jsp
For those of you who don''t know us, we are Bryan Cantrill, Mike Shapiro
and
Adam Leventhal -- we are the engineers behind DTrace. There are many other
DTrace personalities ("personalities.d"?) here or lurking, so let us
take a
second to introduce you to some of your fellow list members:
- Jarod Jenson. First person to see or use DTrace outside of Sun. Holds
most of the American indoor DTrace records, including Biggest
Performance Win, Fastest Time to 2X, and Most Performance Wins (Career).
The Babe Ruth of DTrace.
- Jon Haslam. Avid DTrace user, developer of DTrace visualization tools,
and the canonical DTrace early adopter:
http://blogs.sun.com/roller/page/bmc/20040617#the_early_adopters
- Brendan Gregg. First person to post DTrace scripts on the web. Of
generally twisted mind, Brendan also wrote the first D script
(shellsnoop.d) that is universally described as either "scary" or
"spooky".
- Robert Milkowski. To the best of our knowledge, the first person
outside of Sun to run DTrace in production. Honorary DTrace ambassador
to pl.comp.os.linux and pl.comp.sys.sun.admin.
- Dan Price. On a quest to automate us out of our moonlighting job as
DTrace hucksters, Dan has developed a Java application that can be used
to easily show off the power of DTrace. Perhaps Dan can be pursuaded
to release this under CDDL?
- Alan Hargreaves. Prolific blogger, DTrace user and advocate.
Others from outside Sun will presumably join as OpenSolaris opens to the
general public. As for other DTrace users inside Sun, they''ll be here
as
soon as we transition our internal means of distributing information to
opensolaris.org (see below) -- so you''ll soon meet long-time users of
DTrace
inside of Sun like Gavin Maltby, Jonathan Adams and Bart Smaalders.
But enough pleasantries -- what are the DTrace plans with respect to
OpenSolaris? For starters, we want to open all of our internal DTrace
content and make opensolaris.org the home for all DTrace content going
forward. Specifically:
- We have a DTrace interest list internally at Sun. This list has been
around since the project''s inception, and now has over 300 members.
We
intend to eliminate this list; this opensolaris.org list will become the
canonical DTrace list. We also plan to move the existing dtrace-interest
archives (which consists of over 2500 messages spanning over two years)
to the opensolaris.org list. This will allow you to search the extensive
archives for answers to questions, and will allow you to browse past
design discussions.
- We plan on adding much more content to the DTrace web here on
OpenSolaris. We have an internal DTrace web site, as well as the
BigAdmin site. Our goal is to have both simply point to the
opensolaris.org site, which will be the canonical source for DTrace
information.
- We plan on making public all of our internal presentations on DTrace,
including the very first DTrace presentation from October 1999 -- over
five years ago!
In short, we intend to keep you just as informed as to ongoing DTrace
development as anyone internal to Sun. (Indeed, anyone internal to Sun
who wishes to stay abreast of DTrace development will be directed to
opensolaris.org.)
And where do we need your help? There are a few obvious ways that everyone
can help DTrace:
- Contribute DTrace scripts. We plan to put together a page containing
DTrace recipes, similar to a page that we have internally. We would
like you to contribute your best scripts, along with examples of
how to use them.
- Make additions to the DTrace web pages on opensolaris.org. Because
opensolaris.org is a wiki, anyone can make additions to virtually any
page. Don''t hesitate to make additions or modifications where you
see
fit!
- Let us know where DTrace falls short. In many ways, the most productive
request for enhancement is a description of how DTrace _couldn''t_
help
you solve your problem -- with as much detail about your problem as
possible. This is helpful for you because you can be sure that we
develop exactly the technology you need to solve your real-world problems
-- and it helps us avoid needless feature creep by assuring us that the
enhancement that you''re requesting has real-world application.
And how about those of you who have the itch to edit some source code?
There are a few areas where we see potential for community involvement
in the ongoing development of DTrace:
- Stable providers. The stable providers make available semantically
stable probes in specified parts of the system. We implemented several
of these for Solaris 10 (proc, sched, io, mib, vminfo, sysinfo, fpuinfo),
but it isn''t enough: we need stable providers for every major area
of the
kernel. Some of this is in progress. For example, when he''s not
busy
defending our coding style, Keith Wesolowski on the OpenSolaris team is
leading the charge on an ipc provider. But we need networking
providers (socket and/or tcp and/or ip), an nfs provider, a vm provider,
and probably a few others. It isn''t easy to develop a stable
provider --
it can be surprisingly difficult to develop semantics that are
sufficiently abstract to not overly constrain implementation, but not so
abstract as to be useless. Moreover, we have found that the biggest
challenge can be providing not only the right probes, but the right
arguments for those probes. In some cases, providing the right arguments
can require substantial work on the subsystem. (For example, it would
not have been possible to provide the file information for the io probes
had it not been for Eric Schrock''s pathname caching work -- and even
then
it required some surgery to the I/O subsystem to connect the dots.)
- Stable user-level providers. In Build 67, Adam added support for stable
user-level providers and (in particular) added the plockstat provider
to libc. There are many more of these that can be added to the system.
In particular, it would be valuable to add stable providers to
environments such as MySQL, Apache, Perl, etc.
- Stabilizing and documenting libdtrace. The library interface to DTrace
has become increasingly stable, but we still need to document it and
commit to it. If you want to get involved in this, you can start by
writing your own libdtrace consumer (by copying intrstat(1M) or
dtrace(1M)) -- which will make you appreciate how sorely we need
documentation!
- libdtrace bindings to either languages. We''re currently working
on a JNI interface for libdtrace, but we''d love to see libdtrace
bindings for languages like Python and Perl.
Let us know if you''re interested in any of the above, and
we''ll work on
getting you (and everyone, for that matter) the details required to get
started.
Anyway, welcome. In case you haven''t already inferred it,
we''re thrilled
to have you here -- and we''re thrilled to be here ourselves...
Keep on tracing,
Bryan, Mike and Adam
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
_______________________________________________
DTrace mailing list
DTrace@opensolaris.org
https://www.opensolaris.org/mailman/listinfo/dtrace
Dan Price <dp@eng.sun.com> wrote:> One of the things I''m learning is that we (Sun) are still figuring out > how to open source smaller works without incurring large amounts of > (costly) process. I decided to test this process out, because we have a > lot of "home directory" software in the kernel group (and in the wider > inside-Sun Solaris Community) which we should be sharing with the wider > community going forward.So it seems that you have similar problems with those project as I have with CDDL. If we could find an easy and inexpensive to use license for all projects, this would help everyone. J?rg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don''t have iso-8859-1 schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
G''Day Bryan, DTrace folks, On Sun, 5 Dec 2004, Bryan Cantrill wrote: [...]> > - Brendan Gregg. First person to post DTrace scripts on the web. Of > generally twisted mind, Brendan also wrote the first D script > (shellsnoop.d) that is universally described as either "scary" or > "spooky".Actually, I recently did a spooky demo of Solaris 10, I had people login to a Solaris 10 server and try out commands - and while they were busy typing I brought up execsnoop.d on a data projector screen, # /execsnoop.d TIME UID PID PPID CMD 130867921406 100 18655 17469 ls 130882410539 100 18658 17469 vi /etc/hosts [...] I started asking why people were editing certain files and they were stunned that I ''knew'' what was happening. They eventually saw the screen and were mesmerised by it. DTrace knew all. [...]> - Contribute DTrace scripts. We plan to put together a page containing > DTrace recipes, similar to a page that we have internally. We would > like you to contribute your best scripts, along with examples of > how to use them.My scripts will become much nicer when arguments are optional, at the moment they are a bit ugly. Gee, I could have -d for timestamps, -(erm?)h for human readable timestamps (I noticed the new additions for time formating which are very cool :). ... I could always wrap my D scripts in the Bourne shell, but that would be cheating. Not to mention that seeing -eq''s and ==''s in the same script would be somewhat rude. [...]> And how about those of you who have the itch to edit some source code? > There are a few areas where we see potential for community involvement > in the ongoing development of DTrace: > > - Stable providers. The stable providers make available semantically[...] Cool, many things to think about. A Sun::Solaris::DTrace library for Perl would be interesting, along with Sun::Solaris::Kstat it would make for some killer tools. I already have a Perl /proc interface - this could all combine to give us a prstat with a %I/O and %Net, etc... Brendan [Sydney, Australia] _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
On Mon 06 Dec 2004 at 04:52PM, Shanon Loveridge wrote:> Hey Adam thats excellent news! > > After talking to a few admins I got the feeling that people consider > mdb to be a big dark scary area. I had a look around on the web and > could not find much information on it other than the reference guide > and some examples on blogs.sun.com. > > Because of this I decided a good way to learn would be to write up a > white paper on looking at processes using mdb, which is currently in > progress. If a project is created on onpensolaris.org before I finish > I might have a few questions for the list. Regardless I will submit it > to be put in the project area if people think it is useful.Shanon, One thing we almost always do in the Solaris group is to solicit peer review when creating writeups like this. If you''d like, send along a draft at some point, and I''m sure at least one person hanging out on this list (from Sun or not) will have time to take a look and give you some feedback. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
On Sun, 5 Dec 2004 21:17:20 -0800, Adam Leventhal <ahl@eng.sun.com> wrote:> On Mon, Dec 06, 2004 at 11:59:05AM +1100, Shanon Loveridge wrote: > > ... I would personally > > like to see a mailing list / project area like the dtrace area but for > > mdb / kernel and crash debugging. Is there a team in Sun similar to > > you guys that I could talk to about this ? > > Hey Shanon, > > Great idea. You''re certainly asking the right people -- Mike wrote the > initial version of mdb with some significant contributions from Bryan and > I help to develop it now. I''ll work with the opensolaris.org folks to get > an mdb area to talk about this sort of stuff.Hey Adam thats excellent news! After talking to a few admins I got the feeling that people consider mdb to be a big dark scary area. I had a look around on the web and could not find much information on it other than the reference guide and some examples on blogs.sun.com. Because of this I decided a good way to learn would be to write up a white paper on looking at processes using mdb, which is currently in progress. If a project is created on onpensolaris.org before I finish I might have a few questions for the list. Regardless I will submit it to be put in the project area if people think it is useful. Shanon -- "We can debug relationships, but it''s always good policy to consider the people themselves to be features. People get annoyed when you try to debug them." Larry Wall _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace
On Mon, Dec 06, 2004 at 11:59:05AM +1100, Shanon Loveridge wrote:> ... I would personally > like to see a mailing list / project area like the dtrace area but for > mdb / kernel and crash debugging. Is there a team in Sun similar to > you guys that I could talk to about this ?Hey Shanon, Great idea. You''re certainly asking the right people -- Mike wrote the initial version of mdb with some significant contributions from Bryan and I help to develop it now. I''ll work with the opensolaris.org folks to get an mdb area to talk about this sort of stuff. Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl _______________________________________________ DTrace mailing list DTrace@opensolaris.org https://www.opensolaris.org/mailman/listinfo/dtrace