Re: Actions and Filters

[Mike Cvet <mcvet at redhat dot com>]

On Tue, 2006-08-01 at 09:17 +0800, Yao Qi wrote:
> Hi, Mike, it sounds great!
> Here are some comments about Filters or Actions, and hope they are
> useful to you.
> > To summarize; the available Filters are...
> > Filter by (for both Tasks and Processes, fork()ers and fork()ed):
> > 
> > Name
> > Name of parent
> > Command-line options
> > Executable path
> > Exit value
> descendence of a certain parent.
> If A forks B, B forks C, system admin would like to see what happened
> when A start up, so all the descendence of A should be checked.
> > 

Not a bad idea; since filters already exist for the direct parent of a
process, checking ancestry as well shouldn't be too much of an
extension. I'll generalize for any ancestor older than the direct
parent.

> > Resulting in Actions:
> > 
> > Log custom event
> > Show source code
> > Add observer
> > Print current state
> > Show register values
> > Show memory space values
> Backtrace the current call stack.
> > 

Good idea! Missed that one completely. I'll be hounding Adam for his
backtrace work over the next couple weeks.

> Filters and Actions vary from person to person, and actually, I am
> still not sure what kind of Filters and Actions are most important to
> myself. :)
> 
> However, we could build Actions and Filters framework as scalable as
> possible, so that new Filters and Actions could be added into easily.
> 

The scalability of Actions should multiply once the
execute-external-binary/script Action is put in place. Then, the user
will be able to instantiate any number of custom events via a script
they write themselves - however, external to Frysk.

As far as adding more Actions and Filters as developers, the interface
is fairly straightforward. All that is needed is a new class overriding
a couple methods - especially the filter() and execute() methods.