A .d file defining a provider has an element called provider. This is the first
element of the four tuple that uniquely defines a probe. The others are module
name, function name and probe name.
Assuming the following content
provider myprov {
probe enterA;
probe enterB;
}
Doing a listing of all probes matching myprov give me something like
myprov1234:myprov:function1:enterA
myprov1234:myprov:function2:enterB
Here I see that provider and module have too much redundancy in their naming. I
would love to specify a different module name, in order to create a hierarchy or
separation of roles. However I see no way to define the name for my module. Can
this be done? If so, how?
Also feel the above provider specification is bad practice from at least a
readability point of view. Both enterA and enterB should be called enter. The
actual probes are still uniquely defined, since the function names are
different. However running
provider myprov {
probe enter;
probe enter;
};
through dtrace to get an object file gets me an error: already defined.
Even if they have different paramets sets and/or types this "already
defined" pops up.
Can this be resolved?
Thanks
Paul
--
This message posted from opensolaris.org
Hi Paul, We made a decision early on to keep the module and function components uncostomizable and tied to the actual shared object and function which contain the USDT probes. Some people have found it annoying that dtrace -l displays what are essentially implementation details, and to that end we''ve discussed hiding by default the components of a provider according to some stability settings. In other words, dtrace -l would only list the elements of the probe tuple that should be specified by the user (e.g. plockstat123:::mutex-acquire not plockstat123:libc.so.1::mutex-acquire). If you give a more concrete description of what you''re trying to do, we may be able to suggest a solution that fits with DTrace conventions. Adam On Mon, Jan 14, 2008 at 07:13:41AM -0800, Paul van den Bogaard wrote:> A .d file defining a provider has an element called provider. This is the first element of the four tuple that uniquely defines a probe. The others are module name, function name and probe name. > > Assuming the following content > > provider myprov { > probe enterA; > probe enterB; > } > > > Doing a listing of all probes matching myprov give me something like > > myprov1234:myprov:function1:enterA > myprov1234:myprov:function2:enterB > > Here I see that provider and module have too much redundancy in their naming. I would love to specify a different module name, in order to create a hierarchy or separation of roles. However I see no way to define the name for my module. Can this be done? If so, how? > > Also feel the above provider specification is bad practice from at least a readability point of view. Both enterA and enterB should be called enter. The actual probes are still uniquely defined, since the function names are different. However running > > provider myprov { > probe enter; > probe enter; > }; > > through dtrace to get an object file gets me an error: already defined. > > Even if they have different paramets sets and/or types this "already defined" pops up. > Can this be resolved? > > Thanks > Paul > > > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Mon, Jan 14, 2008 at 07:46:31PM +0100, Paul van den Bogaard wrote:> If I understand you correctly it is not possible to specify a module > name. If this is the case than indeed it seems a good thing to remove > redundancy in the listing of probes (meaning removing the module name). > On the other hand there is now an artificial (driven by > implementation) separation between "system" probes and USDTs. My > initial feeling for this is not too positive. But than I do not know > the motivations that restulted in this decision.How is there a difference between system providers and USDT providers? Probes in the kernel reflect their containing kernel module; probes in user-land reflect their containing loadable object.> The thing that I would like though is the ability to specify probes > that have the same probename (all in the same provider). The > probename is in some situation a local thing. If I enter a function > it is that function I enter. So provider::function1:enter is the > unique key for it. However this is not possible. Being forced to use > provider::function1:enter1, provider::function2:enter2 etc is too > artificial. Here internal implementation things force me in a > direction I do not want. Implementing (informational) DTrace static > probes is not something done lightly. Although the syntax for > implementing them is rather straight forward the selection of proper > names in proper places is hard. I do not like it that it becomes even > more tougher due to these implementation constraints.Is this because you want to have different arguments to the two different ''entry'' probes? You could effect that by using the old DTRACE_PROBE*() syntax which provides no mechanism for type checking. Again, it would be helpful to understand what you''re trying to do. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
Adam, On 14-jan-2008, at 19:58, Adam Leventhal wrote:> On Mon, Jan 14, 2008 at 07:46:31PM +0100, Paul van den Bogaard wrote: >> If I understand you correctly it is not possible to specify a module >> name. If this is the case than indeed it seems a good thing to remove >> redundancy in the listing of probes (meaning removing the module >> name). >> On the other hand there is now an artificial (driven by >> implementation) separation between "system" probes and USDTs. My >> initial feeling for this is not too positive. But than I do not know >> the motivations that restulted in this decision. > > How is there a difference between system providers and USDT providers? > Probes in the kernel reflect their containing kernel module; probes in > user-land reflect their containing loadable object.Ah, it is your kernel centric view vs my application view. As the kernel (decent) apps also consist of modules. If the module hierarchy is reflecting behavioural components than their names have value. Not only for developers but for adminstrators, performance tuners etc. In order to assist these people we could Implement a set of DTrace probes that somehow reflect the hierarchy of the software: software modules. This is why I strongly believe that an ability to define probes and an ordering in modules would be real beneficial for non kernel related software. Once we speak the language of the application we lower the threshold for those administrators/tuners helping them to accept our solutions and see the value that they offer.> >> The thing that I would like though is the ability to specify probes >> that have the same probename (all in the same provider). The >> probename is in some situation a local thing. If I enter a function >> it is that function I enter. So provider::function1:enter is the >> unique key for it. However this is not possible. Being forced to use >> provider::function1:enter1, provider::function2:enter2 etc is too >> artificial. Here internal implementation things force me in a >> direction I do not want. Implementing (informational) DTrace static >> probes is not something done lightly. Although the syntax for >> implementing them is rather straight forward the selection of proper >> names in proper places is hard. I do not like it that it becomes even >> more tougher due to these implementation constraints. > > Is this because you want to have different arguments to the two > different > ''entry'' probes? You could effect that by using the old DTRACE_PROBE*() > syntax which provides no mechanism for type checking.No, this too might be due to the difference between us how we are viewing the world. The enter has a meaning. For some functions just entering and returning are very meaningfull concepts. The ability to name a probe "enter" is therefore real. This can happen many times. In DTrace this is not possible. We need to fall back to schemes of redundancy (function1_enter, function2_enter while function1, and function2 are already in the probefunction name) or through other artificial constructs like enter1, enter2, ... Once more the ability to select a name, not hindered by implementation details, is really helpfull for the above stated objective.> > Again, it would be helpful to understand what you''re trying to do.I am trying to create static probes PostgreSQL database, and memcached. I just stumbeled over these constraints and posted this with a question if there constraints are for real. It is the constraint that is bugging me. In my current context and in many to come. Just the nature of the beast I guess ;^) Hope the above clarifies it a little. Thanks Paul -- This message posted from opensolaris.org
On Fri, Jan 25, 2008 at 12:58:33AM -0800, Paul van den Bogaard wrote:> > How is there a difference between system providers and USDT providers? > > Probes in the kernel reflect their containing kernel module; probes in > > user-land reflect their containing loadable object. > > Ah, it is your kernel centric view vs my application view. As the > kernel (decent) apps also consist of modules. If the module hierarchy > is reflecting behavioural components than their names have value.[ snip ] Both the kernel and user-land application can decompose into functional modules. Some of those functional modules reside in their own actual module (kernel module or dynamic library), but some are clumped together for the case of code simplicity, build ease, etc. In both cases, DTrace exposes the actual module breakdown rather than the one tied to the program logic. User- land and the kernel are treated exactly the same in this regard.> I am trying to create static probes PostgreSQL database, and > memcached. I just stumbeled over these constraints and posted this > with a question if there constraints are for real. It is the > constraint that is bugging me. In my current context and in many to > come. Just the nature of the beast I guess ;^) > Hope the above clarifies it a little.It does. The stable portion of SDT probes are the provider name and the probe name, both of which you can choose. If you''re instrumenting two radically different modules, you may consider adding multiple providers to distinguish the two or adding more information to the probe name: postgresql-module:::something postgresql:::module-something Perhaps it was a mistake to draw up such an exacting policy about the meaning of the module and function names for SDT and USDT probes, but I think it''s one we''re committed to, and its deficiencies can certainly be worked around. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl