Re: [Fault-injection-developer] RE: [PATCH]Rewrite of fi_core.c using sysfs
Status: Alpha
Brought to you by:
rustyl
From: Rusty L. <ru...@li...> - 2002-12-17 16:36:25
|
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 |