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

[Zhuang, L. <lou...@in...>]

> 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?
I think fi_core should know these things more then mucking. In my meaning,
fi_core should know all these things such as 'cancel IO write', 'corrupt IO
access' etc. and tell interceptor what they should do. if interceptor can
not understand this hint or do this hits, it can ignore it w/ a warning. we
should not assign interceptor too many responsibilities... 
*  Interceptors should only intercept somthing wanted by others, report this
intercepting event and do mucking what they can underderstand and can also
do. 
*  fi_core should assign triggers to interceptors, recieve intecepting
events from interceptors, computing logic to determine what should do and
tell interceptor do it.
Interceptors should not compute logic because they *only* have information
about trigger... fi_core should delegate mucking to interceptors beacuse it
do not know hardware details. 
 
> Also, wouldn't you want your trigger executed
> with as little overhead as possible if your
Yes, I want. But I perfer to minimize overhead as little as possible when no
triggers. When there are triggers, there are two more overheads, one is
judging if the pagefault is caused by FITH, the other is processing the
trigger if pagefault is caused by trigger. The first overhead can be
optimized by searching algorithm. Then second overhead is *unavoidable*. the
overhead is as much as what we do in FI. Less we do, Less overhead is...
> 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.
In our view, we'll update the limited computing  logic code with code
segment. So I do not think inline computing logic code is very helpful.