Re: [dtrace-discuss] Leopard DTrace source
On Dec 18, 2007, at 12:43 AM, Jon Haslam wrote: Hi James, I just got word, the OS X dtrace source has been posted: http://www.opensource.apple.com/darwinsource/10.5/dtrace-48/ In the interest of full disclosure, the sources as they sit will not build correctly. This isn't a plot, plan, or other scheming, its simply that they depend on Apple private frameworks that don't have public headers. Discussions on how to release a buildable set of sources are ongoing, I'll send another update when I can. I may have missed it but I couldn't see the uts source here. Do you have a pointer to it somewhere? Jon, The darwin equivalent of uts is called xnu, and is available at: http://www.opensource.apple.com/darwinsource/10.5/xnu-1228/ James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dpp(1) - a modest proposal
At 08:13 -0500 12/18/07, James Carlson wrote: Or you can skip that step and use m4 or even Perl to generate your extremely complicated D code. Yes, you could. I've also used Erb and sh for this sort of thing. However, there are any number of D scripts out there that use cpp macro expansions, and a change would break them. Also, as you mention, there is the ability to read in system header files. All told, backward compatibility is not to be discarded lightly. If it _is_ compatible, then why not just make dpp be the new cpp? In other words, why not just enhance or replace cpp itself, and skip the need for a separate utility and special invocation sequence? First, _cpp_ isn't compatible with cpp, as you move from OS to OS. If it were, this whole discussion would not be happening. Second, cpp has been customized, over the years, by the compiler writers, so it can't be changed easily, even assuming cooperative attitudes: % head -11 /usr/bin/cpp #!/bin/sh # # Transitional front end to CCCP to make it behave like (Reiser) CCP: # specifies -traditional # doesn't search gcc-include # # Please beware that this program exists only to provide legacy BSD #software access to cccp. Direct access to the C pre-processor #is deprecated; it is only supported for use by the cc(1) C #compiler. Use of cccp for anything other than C code is a bad #idea. Don't do it. If you want a macro processor, use m4(1). In an sense, I AM asking that we enhance or replace cpp itself, but call the result dpp, to avoid any confusion or conflict with the local variant of cpp. Finally, speaking of enhancements, I can think of some (eg, embedding macro arguments into strings) that would be useful to D, but not to C... -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume [EMAIL PROTECTED] http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Leopard DTrace source
On Dec 18, 2007, at 12:48 AM, James McIlree wrote: The darwin equivalent of uts is called xnu, and is available at: http://www.opensource.apple.com/darwinsource/10.5/xnu-1228/ A quick grep picks out the faces in the xnu crowd ;-) $ grep -l -r CDDL HEADER START . ./bsd/dev/dtrace/dtrace.c ./bsd/dev/dtrace/dtrace_subr.c ./bsd/dev/dtrace/fasttrap.c ./bsd/dev/dtrace/fbt.c ./bsd/dev/dtrace/lockstat.c ./bsd/dev/dtrace/profile_prvd.c ./bsd/dev/dtrace/sdt.c ./bsd/dev/dtrace/sdt_subr.c ./bsd/dev/dtrace/systrace.c ./bsd/dev/dtrace/systrace.h ./bsd/dev/i386/dis_tables.c ./bsd/dev/i386/dtrace_subr_x86.c ./bsd/dev/i386/fasttrap_isa.c ./bsd/dev/i386/fasttrap_regset.h ./bsd/dev/i386/fbt_x86.c ./bsd/dev/i386/instr_size.c ./bsd/dev/i386/sdt_x86.c ./bsd/dev/ppc/dtrace_subr_ppc.c ./bsd/dev/ppc/fasttrap_isa.c ./bsd/dev/ppc/fbt_ppc.c ./bsd/dev/ppc/sdt_ppc.c ./bsd/i386/dis_tables.h ./bsd/i386/fasttrap_isa.h ./bsd/ppc/fasttrap_isa.h ./bsd/sys/dtrace.h ./bsd/sys/dtrace_impl.h ./bsd/sys/fasttrap.h ./bsd/sys/fasttrap_impl.h ./bsd/sys/lockstat.h ./bsd/sys/sdt.h ./bsd/sys/sdt_impl.h ./osfmk/mach/i386/sdt_isa.h ./osfmk/mach/machine/sdt.h ./osfmk/mach/ppc/sdt_isa.h ./osfmk/mach/sdt.h And this one shows where worlds collide :-) :-) $ grep -l -r CONFIG_DTRACE . ./bsd/conf/MASTER ./bsd/dev/dtrace/dtrace_glue.c ./bsd/dev/i386/systemcalls.c ./bsd/dev/ppc/systemcalls.c ./bsd/kern/bsd_init.c ./bsd/kern/kern_exec.c ./bsd/kern/kern_exit.c ./bsd/kern/kern_fork.c ./bsd/sys/lockstat.h ./bsd/sys/proc_internal.h ./bsd/sys/user.h ./iokit/conf/MASTER ./libkern/conf/MASTER ./libsa/conf/MASTER ./osfmk/conf/MASTER ./osfmk/i386/bsd_i386.c ./osfmk/i386/genassym.c ./osfmk/i386/i386_lock.s ./osfmk/i386/locks_i386.c ./osfmk/i386/loose_ends.c ./osfmk/i386/pmap.c ./osfmk/i386/thread.h ./osfmk/i386/trap.c ./osfmk/kern/clock.c ./osfmk/kern/clock.h ./osfmk/kern/locks.c ./osfmk/kern/thread.c ./osfmk/kern/thread.h ./osfmk/kern/timer_call.c ./osfmk/mach/machine/sdt.h ./osfmk/ppc/genassym.c ./osfmk/ppc/hw_lock.s ./osfmk/ppc/interrupt.c ./osfmk/ppc/locks_ppc.c ./osfmk/ppc/pmap.c ./osfmk/ppc/trap.c ./pexpert/conf/MASTER ./pexpert/i386/pe_interrupt.c ./security/conf/MASTER SCP -- Steve Peters [EMAIL PROTECTED] ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dpp(1) - a modest proposal
Or you can skip that step and use m4 or even Perl to generate your extremely complicated D code. Yes, you could. I've also used Erb and sh for this sort of thing. However, there are any number of D scripts out there that use cpp macro expansions, and a change would break them. Also, as you mention, there is the ability to read in system header files. All told, backward compatibility is not to be discarded lightly. Generating a D script with some other tool and then launching dtrace with the -C flag doesn't introduce any compatibility problems that I can see. Granted, it means you're using two different macro mechanisms, but you are using them for quite different purposes. On the other hand, swapping out cpp on a given platform for dpp (by using a different dtrace option) does introduce compatibility problems, unless dpp is itself a compatible superset of cpp on that platform -- or somehow a superset of all platforms. It sounds to me like you're proposing that dpp is somehow tied to the usage of dtrace, rather than tied to the needs of the platform, as cpp is. That's what makes this proposal less attractive to me. Cpp is certainly different between OSes, but that also matches the fact that the header file contents and usages are different between OSes. Whatever the preprocessor might do, it needs to process those header files correctly. Jim is correct -- the purpose of -C is to allow system header files to be consumed; the fact that it can be used in D itself is really more artifact than design. So if one would like a fancier preprocessor to allow for richer D scripts, I think the argument to make would be for better support for alternative preprocessors. For example, it would be convenient to allow preprocessors to be specified via an embedded pragma instead of exclusively on the command line. (This obviously has some slightly tricky issues that would need to be resolved, which is why we haven't done it.) But the point is that the cpp that DTrace uses by default must be the one that is used by default on the system header files -- or as close to that cpp as possible. - Bryan -- Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Announcing dtrace.conf(08)
All, dtrace.conf -- the DTrace (un)conference -- is on! dtrace.conf(08) will be held here in San Francisco on March 14, 2008. Details are available on the dtrace.conf wiki: http://wikis.sun.com/display/DTrace/dtrace.conf Thank you -- all of you -- for your ongoing interest in DTrace, and hope to see you in San Francisco in March! - Bryan, on behalf of Team DTrace -- Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Newbie - Timestamp, process_id , thread_id, cpu_usage
Hi Gurus I'm new to DTrace and in need help to solve a small problem. Could you help sharing be showing a DTrace example and outputs on display these information of a process ? I'm hoping to print out a display similar to this below: Timestamp, process_id , thread_id, cpu_usage% 1, 1, 5, 10 Any help is appreciated. -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Newbie - Timestamp, process_id , thread_id, cpu_usage
Hi Gurus I'm new to DTrace and in need help to solve a small problem. Could you help sharing be showing a DTrace example and outputs on display these information of a process ? I'm hoping to print out a display similar to this below: Timestamp, process_id , thread_id, cpu_usage% 1, 1, 5, 10 Any help is appreciated. You can do something like this with DTrace, but you don't have to. You can either use existing tools [like prstat(1M)] or write your own /proc reader. I can send you an example in Perl if you need one. - akolb ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Announcing dtrace.conf(08)
Colin, I love this slight typo... If you're interesting, please sign up below, indicating (or upgrading) the likelihood of your attending. ^ can'o'worms Its not a typo; its a grammato. your attending should be your attendance - probably not the you're attending that you may be alluding to; which would not fit the phrase/sentence at all (it would have to be likelihood that you're attending; which would be OK). The best bit is that if you are not interesting, then the event is not for you. Regards... Sean. (OK, I know that the use of ... is meaningless; and that OK should not be capitalised (UK (the correct) spelling)). /can'o'worms ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Leopard DTrace source
On Mon, Dec 17, 2007 at 11:04:38PM -0800, James McIlree wrote: I just got word, the OS X dtrace source has been posted: http://www.opensource.apple.com/darwinsource/10.5/dtrace-48/ In the interest of full disclosure, the sources as they sit will not build correctly. This isn't a plot, plan, or other scheming, its simply that they depend on Apple private frameworks that don't have public headers. Discussions on how to release a buildable set of sources are ongoing, I'll send another update when I can. Good news, thanks James. I don't need to build on OS X because I don't have any Apple machines. :-) -- John Birrell ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] DT_Logger 0.2
I am pleased to announce the 0.2 release of DT_Logger (a DTrace-based OS logger): DT_Logger collects coarse logging information (e.g., file access, process and thread creation, signals), using Sun's DTrace tool. DT_Logger is known to run on Mac OS X 10.5 and Solaris 10, but it should be portable to any Unixish system that supports DTrace and Perl. As the version number indicates, this is Very Early Software, in great need of feedback, patches, etc. Here's the URL: http://www.cfcl.com/twiki/bin/view/Projects/Morinfo/DT_Logger Version 0.2Portability release (2007.1216) This version adds portability and tidies up a bit. Light testing indicates that it works on both Mac OS X and Solaris. The release: - compresses archive files, after processing - defines default probe sets for each operating system - removes (broken) code for syscall:::exec* - slightly modifies the (intermediate) DTL format - splits config.d out of probes.d - works around some cpp(1) portability problems - works around some odd locations (in Solaris) for cpp(1) -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume [EMAIL PROTECTED] http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dpp(1) - a modest proposal
Peculiarly, in my rather extensive use of cpp with D, I hadn't even _considered_ the issue of using it to import and process *.h files. Obviously, my needs are rather out of the mainstream! The way I got into all of this was that Leopard's -C option failed me, so I started running cpp(1) as a separate step. Given that I was doing some rather baroque things with macros, being able to see the expanded form of the code was quite handy. Then, however, I ran into the facts that (a) the Leopard cpp is not by any means standard (and I had been relying on some non-standard behavior :-/) and (b) Solaris can't be relied upon to have cpp or even cc on its $PATH. (Interested parties are welcome to peruse my workaround code in DT_Logger-0.2.tgz, as mentioned previously.) In retrospect, I'm not sure that cpp was necessarily the best choice as a preprocessor for the sorts of things I'm doing. I started out using it because it was there (and because I needed some way to make my code a bit shorter and cleaner). I may also have thought that, by choosing cpp, I was making my code easier for others to read. In any case, I intend to give the issue some serious thought, as I work further on DT_Logger. Perhaps I need a program generator of some sort; certainly that could make my code substantially shorter! At 10:42 -0500 12/18/07, James Carlson wrote: Would you need that feature in dpp if D itself had string pasting? If changes to D itself are under consideration, here are a couple of wish list items: * compile-time string concatenation foo + bar = foobar Although, to be honest, my main motivation for wanting this is the fact that adding a %s to my printf's for the variable name caused my programs to run out of kernel space. If Leopard had a way to increase this space, I might not have cared. * more flow-control constructs (if, case, ...) I'm not asking for looping, guys, just decent alternation... At 10:42 -0500 12/18/07, James Carlson wrote: What other preprocessor features are specific to D rather than C? I'm not sure, but I'll give it some thought. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume [EMAIL PROTECTED] http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
