Re: precompiled probing scenarios

[David Smith <dsmith@redhat.com>]

Stone, Joshua I wrote:
> On Thursday, October 19, 2006 12:50 PM, David Smith wrote:
>> Frank Ch. Eigler wrote:
>>> kernel.function("*") should match exactly what was there before.
>>> Probes on module("*").FOO would be redefined to mean something like
>>> "all modules that we know at translation time that *might* exist,
>>> that also happen to be *loaded* at run time.  This aspect of wildcard
>>> expansion would thus take place at run time rather than translate
>>> time.  It just so happens that the same module might probe a greater
>>> or lesser number of modules on an actual system.  With that proviso,
>>> a script-source-level hash still seems to work.
>> [...]
>> The hash is computed using the following data:
>> [...]
>> - pass 2 script output
>> [...]
>> Stuff left to do:
>>
>> - Testing, testing, testing
>> - Correct module handling (which Frank outlined above)
> 
> Actually, correct module handling should already be covered if you're
> hashing the pass-2 output.  Pass-2 is elaboration, which uses debuginfo
> to locate the actual probe points.  Suppose I run a script like this:
> 
> 	probe module("*").function("*interrupt*") { log(probefunc()) }
> 
> Pass-2 output will include all of the probe points matching my wildcard:
> 
>   ...
>   module("ahci").function("ahci_interrupt@drivers/scsi/ahci.c:889"),
>  
> module("libata").function("ata_interrupt@drivers/scsi/libata-core.c:4198
> "),
>   ...
> 
> If I then load a new module that also has a "*interrupt*" function, the
> pass-2 output will include the new probe point, and will thus get a
> different hash.

Good point.  But, if Frank's suggestion was implemented, you could still 
use the same cached module, since wildcard expansion would happen at 
runtime.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)