RE: [Fault-injection-developer] RE: [PATCH]Rewrite of fi_core.c u sing sysfs

[Wang, S. <sta...@in...>]

> > > I agree that the core is the proper location for putting
> > > common (i.e. 'core') functionality that is exported for 
> > > other code to use.
> > > 
> > > This doesn't explain why you want execute_trigger inside
> > > the core.  I would argue that each interceptor does not
> > > want to execute a trigger in exactly the same way.  
> > As you see, execute_trigger handles an intercepted event,
> > and look up the wp table to decide how to injection fault. It
> > will be need by all the other interceptor, IO/PCI config etc. 
> > Why not we move it into fi_core.c and share it among all
> > interceptors.
> > 
> > -Stan
> > 
> > > 
> > > Could you further explain your position?
> > > 
> > 
> 
> When the pf interceptor executes a trigger all it 
> really does is:
> 1. apply some filter criteria contained in the 
>    trigger to decide if anything should be done
> 2. If something should be done then apply some 
>    operations on the data passed to the handler
> 3. store the manipulated data back where it was
>    read from
> 
> It seems to me that something more then just 
> mucking up a chunk of data could be implemented 
> by an interceptor.  Doesn't this seem like an 
> artificial limitation?
> 
> Also, wouldn't you want your trigger executed
> with as little overhead as possible if your
> interceptor is getting triggered very often
> (like in a page fault handler.)  It seems like it
> would be a good idea to include the trigger execution
> inline instead of making yet another function call.
According to what should be done in execute_trigger,
I don't think that include it inline will reduce much overhead.
Also, if there is any fault that should be injected, we don't really
care the system's performance; if there isn't, we could found other
way to reduce the overhead (using global flag?).
How do you think about it :)

-Stan 

> 
>         -rusty
>