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

[Rusty L. <ru...@li...>]

Ok, you made some good points.  I think the model I implemented in my 
patch needs some tweaking.  Let me try to summarize all the feedback in a
new email along with a fresh description of what the fault injection core 
should provide. 

I should have something together by morning in Asia.

    --rusty

> > 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.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer