From max at bruningsystems.com Tue May 3 16:46:47 2005 From: max at bruningsystems.com (Max Bruning) Date: Tue, 3 May 2005 16:46:47 -0700 (PDT) Subject: [DTrace] schedctl-yield args problem Message-ID: <3004.68.113.59.161.1115164007.squirrel@www-yellow.garlic.com> Hi. According to the dtrace guide, the schedctl-yield probe in the sched provider has two args[]. args[0] is supposed to be a lwpsinfo_t and args[1] is supposed to be psinfo_t. Here are 2 different scripts, each with errors pertaining to the args. /*foo.d*/ sched:::schedctl-yield { printf("%s has schedctl-yielded\n", args[1]->pr_fname); } Here's the error: # dtrace -s foo.d dtrace: failed to compile script foo.d: line 4: args[ ] may not be referenced because probe description sched:::schedctl-yield matches more than one probe # Here's the second try: /*foo1.d*/ sched::ts_yield:schedctl-yield { printf("%s has schedctl-yielded\n", args[1]->pr_fname); } Here's the error: # dtrace -s foo1.d dtrace: failed to compile script foo1.d: line 4: no args[ ] are available for probe sched::ts_yield:schedctl-yield # So, what's the story? Does this probe take args? The dtrace guide page on arguments for the sched provider probes says yes. But the output above says no... thanks, max From ahl at eng.sun.com Wed May 4 11:07:23 2005 From: ahl at eng.sun.com (Adam Leventhal) Date: Wed, 4 May 2005 11:07:23 -0700 Subject: [DTrace] schedctl-yield args problem In-Reply-To: <3004.68.113.59.161.1115164007.squirrel@www-yellow.garlic.com> References: <3004.68.113.59.161.1115164007.squirrel@www-yellow.garlic.com> Message-ID: <20050504180723.GC9693@eng.sun.com> Hi Max, It appears that that is a documentation error: The sched:::schedctl-yield probe has one argument and it's an int (the time remaining in the quantum). You've also hit a bug in DTrace, the schedctl-yield probe isn't described properly so even the sole argument isn't accessible through the args[] array. I'll file bugs on both these issues -- thanks for reporting the problem. Adam On Tue, May 03, 2005 at 04:46:47PM -0700, Max Bruning wrote: > > Hi. > According to the dtrace guide, the schedctl-yield probe > in the sched provider has two args[]. args[0] > is supposed to be a lwpsinfo_t and args[1] is > supposed to be psinfo_t. > > Here are 2 different scripts, each with errors pertaining to the > args. > > /*foo.d*/ > sched:::schedctl-yield > { > printf("%s has schedctl-yielded\n", args[1]->pr_fname); > } > > Here's the error: > > # dtrace -s foo.d > dtrace: failed to compile script foo.d: line 4: args[ ] may not be > referenced because probe description sched:::schedctl-yield matches more > than one probe > # > > Here's the second try: > > /*foo1.d*/ > sched::ts_yield:schedctl-yield > { > printf("%s has schedctl-yielded\n", args[1]->pr_fname); > } > > > Here's the error: > > # dtrace -s foo1.d > dtrace: failed to compile script foo1.d: line 4: no args[ ] are available > for probe sched::ts_yield:schedctl-yield > # > > So, what's the story? Does this probe take args? The dtrace guide > page on arguments for the sched provider probes says yes. But > the output above says no... > > thanks, > max > > > > > > _______________________________________________ > DTrace mailing list > DTrace at opensolaris.org > https://www.opensolaris.org/mailman/listinfo/dtrace -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl From max at bruningsystems.com Wed May 4 15:18:00 2005 From: max at bruningsystems.com (Max Bruning) Date: Wed, 4 May 2005 15:18:00 -0700 (PDT) Subject: [DTrace] schedctl-yield args problem In-Reply-To: <20050504180723.GC9693@eng.sun.com> References: <3004.68.113.59.161.1115164007.squirrel@www-yellow.garlic.com> <20050504180723.GC9693@eng.sun.com> Message-ID: <1576.68.113.59.161.1115245080.squirrel@www-yellow.garlic.com> Hi Adam, I have the same problem with the surrender probe. thanks, max > Hi Max, > > It appears that that is a documentation error: The sched:::schedctl-yield > probe has one argument and it's an int (the time remaining in the > quantum). > > You've also hit a bug in DTrace, the schedctl-yield probe isn't described > properly so even the sole argument isn't accessible through the args[] > array. > > I'll file bugs on both these issues -- thanks for reporting the problem. > > Adam > > On Tue, May 03, 2005 at 04:46:47PM -0700, Max Bruning wrote: >> >> Hi. >> According to the dtrace guide, the schedctl-yield probe >> in the sched provider has two args[]. args[0] >> is supposed to be a lwpsinfo_t and args[1] is >> supposed to be psinfo_t. >> >> Here are 2 different scripts, each with errors pertaining to the >> args. >> >> /*foo.d*/ >> sched:::schedctl-yield >> { >> printf("%s has schedctl-yielded\n", args[1]->pr_fname); >> } >> >> Here's the error: >> >> # dtrace -s foo.d >> dtrace: failed to compile script foo.d: line 4: args[ ] may not be >> referenced because probe description sched:::schedctl-yield matches more >> than one probe >> # >> >> Here's the second try: >> >> /*foo1.d*/ >> sched::ts_yield:schedctl-yield >> { >> printf("%s has schedctl-yielded\n", args[1]->pr_fname); >> } >> >> >> Here's the error: >> >> # dtrace -s foo1.d >> dtrace: failed to compile script foo1.d: line 4: no args[ ] are >> available >> for probe sched::ts_yield:schedctl-yield >> # >> >> So, what's the story? Does this probe take args? The dtrace guide >> page on arguments for the sched provider probes says yes. But >> the output above says no... >> >> thanks, >> max >> >> >> >> >> >> _______________________________________________ >> DTrace mailing list >> DTrace at opensolaris.org >> https://www.opensolaris.org/mailman/listinfo/dtrace > > -- > Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl > From ahl at eng.sun.com Wed May 4 23:49:01 2005 From: ahl at eng.sun.com (Adam Leventhal) Date: Wed, 4 May 2005 23:49:01 -0700 Subject: [DTrace] schedctl-yield args problem In-Reply-To: <1576.68.113.59.161.1115245080.squirrel@www-yellow.garlic.com> References: <3004.68.113.59.161.1115164007.squirrel@www-yellow.garlic.com> <20050504180723.GC9693@eng.sun.com> <1576.68.113.59.161.1115245080.squirrel@www-yellow.garlic.com> Message-ID: <20050505064901.GC18380@eng.sun.com> Same issue. I'll update the bugs to examine all the SDT probes. Adam On Wed, May 04, 2005 at 03:18:00PM -0700, Max Bruning wrote: > > Hi Adam, > I have the same problem with the surrender probe. > > thanks, > max > > > Hi Max, > > > > It appears that that is a documentation error: The sched:::schedctl-yield > > probe has one argument and it's an int (the time remaining in the > > quantum). > > > > You've also hit a bug in DTrace, the schedctl-yield probe isn't described > > properly so even the sole argument isn't accessible through the args[] > > array. > > > > I'll file bugs on both these issues -- thanks for reporting the problem. > > > > Adam > > > > On Tue, May 03, 2005 at 04:46:47PM -0700, Max Bruning wrote: > >> > >> Hi. > >> According to the dtrace guide, the schedctl-yield probe > >> in the sched provider has two args[]. args[0] > >> is supposed to be a lwpsinfo_t and args[1] is > >> supposed to be psinfo_t. > >> > >> Here are 2 different scripts, each with errors pertaining to the > >> args. > >> > >> /*foo.d*/ > >> sched:::schedctl-yield > >> { > >> printf("%s has schedctl-yielded\n", args[1]->pr_fname); > >> } > >> > >> Here's the error: > >> > >> # dtrace -s foo.d > >> dtrace: failed to compile script foo.d: line 4: args[ ] may not be > >> referenced because probe description sched:::schedctl-yield matches more > >> than one probe > >> # > >> > >> Here's the second try: > >> > >> /*foo1.d*/ > >> sched::ts_yield:schedctl-yield > >> { > >> printf("%s has schedctl-yielded\n", args[1]->pr_fname); > >> } > >> > >> > >> Here's the error: > >> > >> # dtrace -s foo1.d > >> dtrace: failed to compile script foo1.d: line 4: no args[ ] are > >> available > >> for probe sched::ts_yield:schedctl-yield > >> # > >> > >> So, what's the story? Does this probe take args? The dtrace guide > >> page on arguments for the sched provider probes says yes. But > >> the output above says no... > >> > >> thanks, > >> max > >> > >> > >> > >> > >> > >> _______________________________________________ > >> DTrace mailing list > >> DTrace at opensolaris.org > >> https://www.opensolaris.org/mailman/listinfo/dtrace > > > > -- > > Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl > > -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl From brendan.gregg at tpg.com.au Sat May 7 18:19:36 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Sun, 8 May 2005 11:19:36 +1000 (EST) Subject: [DTrace] dtruss and dtrace -c Message-ID: G'Day Folks, I've written a DTrace version of truss, dtruss. It was designed to be safer and less of a burden than running truss, and so far has benchmarked quite noticably better in -f follow mode. The following seems like a little bug with dtrace -c, # dtrace -n 'syscall:::entry /pid == $target/ { @num = count(); }' -c date dtrace: description 'syscall:::entry ' matched 227 probes Sun May 8 11:07:28 EST 2005 dtrace: pid 2412 has exited 24 # truss -c date Sun May 8 11:08:26 EST 2005 [...] -------- ------ ---- sys totals: .000 40 1 usr time: .001 elapsed: .010 DTrace sees 24 syscalls, truss sees 40. Also aggregating on the syscall name (as done at the bottom of chapter 15 of the answerbook), shows incorrect counts for the syscalls when compared to truss (eg, it shows mmaps only twice). It looks like dtrace is misses syscalls during the early part of the program, up to the close on the filedis for libc.so.1. It only happens with the dtrace -c option. I only noticed it while writing dtruss. Maybe I'm doing something wrong? PS. I'm benchmarking code now and it's taught me a lot about coding for performance such that I've just rewritten many of my existing tools. thanks, Brendan [Sydney, Australia] From ahl at eng.sun.com Sat May 7 18:49:51 2005 From: ahl at eng.sun.com (Adam Leventhal) Date: Sat, 7 May 2005 18:49:51 -0700 Subject: [DTrace] dtruss and dtrace -c In-Reply-To: References: Message-ID: <20050508014951.GA25908@eng.sun.com> > I've written a DTrace version of truss, dtruss. It was designed to be > safer and less of a burden than running truss, and so far has benchmarked > quite noticably better in -f follow mode. Very cool! > The following seems like a little bug with dtrace -c, > > # dtrace -n 'syscall:::entry /pid == $target/ { @num = count(); }' -c date > dtrace: description 'syscall:::entry ' matched 227 probes > Sun May 8 11:07:28 EST 2005 > dtrace: pid 2412 has exited > > 24 > > # truss -c date > Sun May 8 11:08:26 EST 2005 > [...] > -------- ------ ---- > sys totals: .000 40 1 > usr time: .001 > elapsed: .010 > > DTrace sees 24 syscalls, truss sees 40. The difference is when the two start recording data. Truss starts counting events immediately while dtrace -c by default waits until the process has loaded its libraries (preinit) so that the pid provider can trace functions in dynamically loaded objects. To change this behavior, use -xevaltime=exec. That will bring dtrace to within one system call count of truss; truss has some fancy logic to count the return from execve. Adam > Also aggregating on the syscall name (as done at the bottom of chapter > 15 of the answerbook), shows incorrect counts for the syscalls when > compared to truss (eg, it shows mmaps only twice). > > It looks like dtrace is misses syscalls during the early part of the > program, up to the close on the filedis for libc.so.1. It only happens > with the dtrace -c option. > > I only noticed it while writing dtruss. Maybe I'm doing something wrong? > > PS. I'm benchmarking code now and it's taught me a lot about coding for > performance such that I've just rewritten many of my existing tools. > > thanks, > > Brendan > > [Sydney, Australia] > > _______________________________________________ > DTrace mailing list > DTrace at opensolaris.org > https://www.opensolaris.org/mailman/listinfo/dtrace -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl From brendan.gregg at tpg.com.au Mon May 9 00:48:04 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Mon, 9 May 2005 17:48:04 +1000 (EST) Subject: [DTrace] dtruss and dtrace -c In-Reply-To: <20050508014951.GA25908@eng.sun.com> Message-ID: G'Day Adam, On Sat, 7 May 2005, Adam Leventhal wrote: [...] > > The following seems like a little bug with dtrace -c, [...] > > DTrace sees 24 syscalls, truss sees 40. > > The difference is when the two start recording data. Truss starts counting > events immediately while dtrace -c by default waits until the process has > loaded its libraries (preinit) so that the pid provider can trace functions > in dynamically loaded objects. To change this behavior, use -xevaltime=exec. > That will bring dtrace to within one system call count of truss; truss has > some fancy logic to count the return from execve. Ahh - thanks Adam! :) It was just my fault for not reading this in the docs! dtruss now works much better. I guess I should add more functionality. :) thanks, Brendan From brendan.gregg at tpg.com.au Mon May 9 20:32:27 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Tue, 10 May 2005 13:32:27 +1000 (EST) Subject: [DTrace] using libdtrace Message-ID: G'Day Folks, I thought it would be fun to write a libdtrace consumer in C, and have done so as a demonstration, http://www.brendangregg.com/DTrace/execsnoop.c It's intended as a short demo. The above address is not linked on my public site. Currently the documentation discourages us from using libdtrace, so we really shouldn't be writing dtrace consumers in C anyway at the moment! It's my first attempt, so I imagine I will have missed some tricks to the code. ... Brendan [Sydney, Australia] From brendan.gregg at tpg.com.au Wed May 11 01:15:09 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Wed, 11 May 2005 18:15:09 +1000 (EST) Subject: [DTrace] DTrace Game Message-ID: G'Day Folks, I've written a guessing game in DTrace. The following is the output, # ./guess.d guess.d - Guess a number between 1 and 100 Enter guess 1: 50 Higher... Enter guess 2: 75 Higher... Enter guess 3: 90 Lower... Enter guess 4: 85 Higher... Enter guess 5: 88 Correct! That took 5 guesses. Please enter your name: Brendan Gregg Previous high scores, Fred Nurk 4 Brendan Gregg 5 # It can be found here, http://www.brendangregg.com/guessinggame.html Or to be specific, http://www.brendangregg.com/Guess/guess.d and is part of a greater project to demo languages by writing the same program in as many as possible (instead of Hello World, something that demonstrates variables, conditionals, loops, input and output, ...). Ok, I know I shouldn't be writing games in DTrace. It was just for fun. And besides - if sed can do arkanoid.... It actually runs system() to use the shell occasionally, for example to trigger a keyboard read, but how the data is then brought into dtrace is done in an amusing dtrace manner. Maybe future versions will be more dtrace (I'm thinking keyboard interrupts). Please enjoy (or howl in agony :), Brendan [Sydney, Australia] From brendan.gregg at tpg.com.au Wed May 11 01:36:04 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Wed, 11 May 2005 18:36:04 +1000 (EST) Subject: [DTrace] zvmstat - DTrace Message-ID: G'Day Folks, vmstat info by zone using DTrace. ... Actually, it should be done in Kstat, and is in Kstat if you use processor sets. If you don't have processor sets, and want vmstat by zone info right now, the following DTrace program may help, # zvmstat 10 ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf global 100 207 0 0 0 0 0 0 0 0 0 0 0 workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 workzone2 138 488 0 0 0 0 0 0 0 0 2014 0 0 workzone3 0 0 0 0 0 0 0 0 0 0 0 0 0 ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf global 0 0 0 0 0 0 0 0 0 0 0 0 0 workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 workzone2 0 0 0 0 0 0 0 0 0 0 0 0 0 workzone3 84 474 0 0 0 0 0 0 0 0 131 0 0 ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf global 2 0 741 3071 0 0 18 0 181 181 0 455 542 workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 workzone2 0 0 0 0 0 0 0 0 0 0 0 0 0 workzone3 14 24132 0 0 0 0 0 0 0 0 1 0 0 [...] The Sun PAE guys here in Adelaide encouraged me to see how doable it was. I expect they will delevop their own versions, for similar data by project... http://www.brendangregg.com/DTrace/zvmstat It's the first release, so next versions should have many more options, and I expect I'll improve upon how various activities are performed (like how I did loops). cheers, Brendan Gregg [Sydney, Australia] (visiting Adelaide, Australia) From dp at eng.sun.com Wed May 11 02:39:47 2005 From: dp at eng.sun.com (Dan Price) Date: Wed, 11 May 2005 02:39:47 -0700 Subject: [DTrace] Re: [Zones] zvmstat - DTrace In-Reply-To: References: Message-ID: <20050511093947.GJ18532@eng.sun.com> On Wed 11 May 2005 at 06:36PM, Brendan Gregg wrote: > G'Day Folks, > > vmstat info by zone using DTrace. > > ... Actually, it should be done in Kstat, and is in Kstat if you use > processor sets. If you don't have processor sets, and want vmstat by zone > info right now, the following DTrace program may help, > > # zvmstat 10 > ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf > global 100 207 0 0 0 0 0 0 0 0 0 0 0 > workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 > workzone2 138 488 0 0 0 0 0 0 0 0 2014 0 0 > workzone3 0 0 0 0 0 0 0 0 0 0 0 0 0 > ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf > global 0 0 0 0 0 0 0 0 0 0 0 0 0 > workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 > workzone2 0 0 0 0 0 0 0 0 0 0 0 0 0 > workzone3 84 474 0 0 0 0 0 0 0 0 131 0 0 > ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf > global 2 0 741 3071 0 0 18 0 181 181 0 455 542 > workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 > workzone2 0 0 0 0 0 0 0 0 0 0 0 0 0 > workzone3 14 24132 0 0 0 0 0 0 0 0 1 0 0 > [...] Neato Brendan. Interesting work. You mention kstats-- but we don't have the data you need in kstats, do we? For psets, it's easy, as we have the various stats per cpu, and so it's just a sum. -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp From brendan.gregg at tpg.com.au Wed May 11 22:55:56 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Thu, 12 May 2005 15:55:56 +1000 (EST) Subject: [DTrace] Re: [Zones] zvmstat - DTrace In-Reply-To: <20050511093947.GJ18532@eng.sun.com> Message-ID: G'Day Dan, On Wed, 11 May 2005, Dan Price wrote: > On Wed 11 May 2005 at 06:36PM, Brendan Gregg wrote: > > G'Day Folks, > > > > vmstat info by zone using DTrace. > > > > ... Actually, it should be done in Kstat, and is in Kstat if you use > > processor sets. If you don't have processor sets, and want vmstat by zone > > info right now, the following DTrace program may help, > > > > # zvmstat 10 > > ZONE re mf fr sr epi epo epf api apo apf fpi fpo fpf > > global 100 207 0 0 0 0 0 0 0 0 0 0 0 > > workzone1 0 0 0 0 0 0 0 0 0 0 0 0 0 > > workzone2 138 488 0 0 0 0 0 0 0 0 2014 0 0 > > workzone3 0 0 0 0 0 0 0 0 0 0 0 0 0 > > [...] > > Neato Brendan. Interesting work. Thanks! :) > You mention kstats-- but we don't have the data you need in kstats, > do we? For psets, it's easy, as we have the various stats per cpu, > and so it's just a sum. Yes, this is exactly what I meant (I just wasn't too clear :). I think the data should be available from Kstat, which it currently isn't AFAIK. This in turn may require creating a zone_sysinfo like the existing cpu_sysinfo. The only Kstat based solution in the meantime would be if psets are used, where it's easy... Brendan From Alan.Hargreaves at Sun.COM Wed May 11 23:00:30 2005 From: Alan.Hargreaves at Sun.COM (Alan Hargreaves - Product Technical Support (APAC)) Date: Thu, 12 May 2005 16:00:30 +1000 Subject: [DTrace] Re: [Zones] zvmstat - DTrace In-Reply-To: References: Message-ID: <4282F0FE.4030409@Sun.COM> Brendan Gregg wrote: > G'Day Dan, > > On Wed, 11 May 2005, Dan Price wrote: >>You mention kstats-- but we don't have the data you need in kstats, >>do we? For psets, it's easy, as we have the various stats per cpu, >>and so it's just a sum. > > > Yes, this is exactly what I meant (I just wasn't too clear :). > > I think the data should be available from Kstat, which it currently isn't > AFAIK. This in turn may require creating a zone_sysinfo like the > existing cpu_sysinfo. > > The only Kstat based solution in the meantime would be if psets are used, > where it's easy... > This actually dovetails quite nicely with an RFE that I logged in November to get these kstats out of the cpu structure: 6199092 kstats need to come out of the cpu structure and become part of the DDI alan. From brendan.gregg at tpg.com.au Mon May 16 15:32:41 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Tue, 17 May 2005 08:32:41 +1000 (EST) Subject: [DTrace] DTraceToolkit Message-ID: G'Day Folks, Here is the first version, http://www.brendangregg.com/dtrace.html#DTraceToolkit Let me know what you think. And please submit scripts! The toolkit has documentation and templates to get you started. I think the DTraceToolkit's home should be on the OpenSolaris site somewhere, as a community effort. I currently can't edit the DTrace section, maybe someone could give me the necessary access if it seems a good idea? Also, if there are no objections, I'll look through /usr/demo/dtrace to see what can be documented, and put in the kit. That sounds pretty odd, but the toolkit is much more than just the scripts - it's about presenting scripts supported by man pages, examples, and discussion docs. So it may encourage people to use what they may normally have glanced over in /usr/demo/dtrace. I'll make it clear their origin, with links to the answerbook etc. Oh - when I do mention the answerbook, is it safe to use Chapter numbers or should I stick to titles? Just checking in case the numbers are likely to change. Well, the toolkit has some new cool stuff - dapptrace, dappprof, ... but I've run out of time with a few more ideas not complete yet. They'll be in the next rev, I've got a plane to catch (not sure I'll have decent internet access over the next 5 days BTW!). enjoy, Brendan [Sydney, Australia] From rmilkowski at task.gda.pl Mon May 23 08:00:11 2005 From: rmilkowski at task.gda.pl (Robert Milkowski) Date: Mon, 23 May 2005 17:00:11 +0200 Subject: [DTrace] USDT - naming freedom Message-ID: <636421387.20050523170011@task.gda.pl> Hello dtrace, Why is it that only provider and probe (last part) name are allowed to be specified in a program? Function name is inserted automatically as a function name in which probe is fired - but it's somewhat ugly. I would really like to specify my own probes like: wpserverPID:mail-io:MailDelete:entry as an USDT probe. Right now all I can do is: wpserverPID:::MailDelete-entry where module and function names would be put automatically. Why is that? Could it be extended to allow specify all names? -- Best regards, Robert mailto:rmilkowski at task.gda.pl From mws at eng.sun.com Mon May 23 09:54:31 2005 From: mws at eng.sun.com (Michael Shapiro) Date: Mon, 23 May 2005 09:54:31 -0700 (PDT) Subject: [DTrace] USDT - naming freedom In-Reply-To: <636421387.20050523170011@task.gda.pl> from Robert Milkowski at "May 23, 2005 05:00:11 pm" Message-ID: <200505231654.j4NGsV1k105803@poptart.eng> > Hello dtrace, > > Why is it that only provider and probe (last part) name are allowed > to be specified in a program? Function name is inserted > automatically as a function name in which probe is fired - but it's > somewhat ugly. > > I would really like to specify my own probes like: > > wpserverPID:mail-io:MailDelete:entry > > as an USDT probe. > Right now all I can do is: > > wpserverPID:::MailDelete-entry > > where module and function names would be put automatically. > > Why is that? Could it be extended to allow specify all names? > We want those fields to reflect the true module and function name, which is why they are filled in for you. Remember that you can enable your probles using only provider and name, e.g. io:::start wpserverPID:::MailDelete-entry so you don't need to know the module and function to use them. Another reason function names may be "ugly" today is because they are mangled C++ names: we are working on some features to handle C++ names better. -Mike -- Mike Shapiro, Solaris Kernel Development. From rmilkowski at task.gda.pl Tue May 24 01:07:55 2005 From: rmilkowski at task.gda.pl (Robert Milkowski) Date: Tue, 24 May 2005 10:07:55 +0200 Subject: [DTrace] USDT - naming freedom In-Reply-To: <200505231654.j4NGsV1k105803@poptart.eng> References: <200505231654.j4NGsV1k105803@poptart.eng> Message-ID: <819738049.20050524100755@task.gda.pl> Hello Michael, Monday, May 23, 2005, 6:54:31 PM, you wrote: >> Hello dtrace, >> >> Why is it that only provider and probe (last part) name are allowed >> to be specified in a program? Function name is inserted >> automatically as a function name in which probe is fired - but it's >> somewhat ugly. >> >> I would really like to specify my own probes like: >> >> wpserverPID:mail-io:MailDelete:entry >> >> as an USDT probe. >> Right now all I can do is: >> >> wpserverPID:::MailDelete-entry >> >> where module and function names would be put automatically. >> >> Why is that? Could it be extended to allow specify all names? >> MS> We want those fields to reflect the true module and function name, MS> which is why they are filled in for you. Remember that you can MS> enable your probles using only provider and name, e.g. MS> io:::start MS> wpserverPID:::MailDelete-entry I know, but still it's less flexible. We want to expose some probes to non-developers folks and such naming is only confusing for them and is less flexible for us (no easy hierarchy, etc.). As we do have several logical modules it would be ok to group them under module names, etc. - like with io provider where you can specify io:nfs::start if you only nfs IOs or io:::start if you want all. MS> so you don't need to know the module and function to use them. Another MS> reason function names may be "ugly" today is because they are mangled C++ MS> names: we are working on some features to handle C++ names better. -- Best regards, Robert mailto:rmilkowski at task.gda.pl