RE: [Fault-injection-developer] [RFC] command in '/sys/triggers/c tl' is changed

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

> Before, I had envisioned a trigger being created for a 'type' 
> of interceptor, 
 The very reason is 'the type of interceptor is duplicated and confused with
Watchpoint Type'. Users, even developer like me ;-), are confused why there
are interceptor type in param 3 and watchpoint type in param 5.

> not a specific interceptor.  This allows for many-to-one 
> relationship between
> interceptors and triggers, and also allows triggers and 
> interceptors to be
> install independent of each other.
> 
> Your proposal infers a one-to-one relationship between 
According to the definition of interceptor, "a component that knows how to
intercept some specific type of kernel level event or action to enable the
fault injection core to 'hook' into event or action and take some action", I
can not find out any meaningful usage of one-to-many relationship between
trigger and interceptor. 
And more, there might be several implementation for a kind of interceptor
(DBP for PIO and DR for PIO, for example). But a trigger should only attach
one of them.

> triggers and interceptors
> and requires interceptors to be installed before triggers are 
> installed.
It is one of my concerns indeed. Your explanation is much clearer than mine.
;-> If needed, the trigger can be inserted before interceptor is loaded
whether the specified param is type or name.

> 
> So... is this an unexpected side effect or an unstated assumption?
Yes, maybe we should put these information into README

> 
> Don't get me wrong.  I'm not sure that I am against 
> formalizing a one-to-one
> relation, but we need for this to not just be an undocumented 
> side effect, but
> an up front design decision so we are all working towards the 
> same goal.
> 
> Specifically:
> 
> What SHOULD be our relationship between triggers and interceptors?
>   a. one trigger associated with one interceptor
>   b. one trigger associated with many interceptors
> 
> What SHOULD be our relationship between triggers and code segments?
>   a. one trigger associated with one code segment
>   b. one trigger associated with many code segments
> 
> My opinion:
> 
> I think we could keep a fairly simple yet flexible design by 
> choosing (a) a 
> single trigger always be associated with a single 
> interceptor, and (b) allow
> for multiple code segments to be attached to any given trigger.
Aggree! ;-> That's my preference too.

> 
> In fact we could totally drop the whole notion of an 
> interceptor 'type' and 
> push all policy statements like 'it does not make sense to 
> associate code 
> segment A with interceptor B' to user space.  
If we use interceptor 'name' in trigger, it is not a policy any more, it is
a *appointment*. So we do not need to guess what user want in kernel part.
Anyway, an easy-to-use utility is always welcome.