This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/6711] need script syntax for extending blacklist


------- Additional Comments From wenji dot huang at oracle dot com  2010-01-22 05:46 -------
Thanks for your review
> I'm not sure that I like "forbid" as a keyword... maybe "noprobe" would be
> better (along the lines of the original "~probe" suggestion).

Taken
> 
> Also, if I understand your patch, it will only work if the forbidden probes are
> listed in the primary script (and possibly tapset files that are included
> incidentally).  We need this to have a global effect, so any defined in a tapset
> blacklist will do their job.

Yes, should be global
> 
> > probe kernel.function("sys_write") {
> > println("wrong")
> > exit()
> > }
> 
> If "sys_write" is blocked, then this probe should be an error as it has no
> resolved probepoints.  This needs to be an error in pass-2, otherwise, the '?'
> and '!' probe resolution won't work correctly.  Listing mode should also not
> report probes that would be blocked.
> 
> I suggest parsing the forbidden probes immediately into a session global list. 
> Resolve those before anything else, so you have a blacklist to compare against
> while resolving the real probes.
> 
> 
> Something else to think about -- the existing blacklist is able to block probes
> based on the function name or filename, regardless of where the probe is in that
> function or file.  As it stands, this "forbid" definition is only blocking exact
> address matches, which is not as useful IMO.

Current method is to derive the probe and noprobes to detailed single probe
list, and then to match the module and address, so no matter the probe or 
noprobe declared in any forms, like "*@kernel/sched.c". The final list will be
tuiple like
        "kernel, addr1, pp_name, etc." 
It can certainly block those probes in noprobes list.

Ofcourse, the drawback is wasted time and space. As you suggested, maybe
to do regular expression matching before deriving probe is better.

I am figuring out the suitable way to implement blacklist. Any suggestion
or comments are welcome.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6711

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]