Before, I had envisioned a trigger being created for a 'type' of interceptor,
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 triggers and interceptors
and requires interceptors to be installed before triggers are installed.
So... is this an unexpected side effect or an unstated assumption?
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.
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.
----- Original Message -----
From: "Zhuang, Louis" <lou...@in...>
To: "FITHML (E-mail)" <fau...@so...>
Cc: "Lynch, Rusty" <rus...@in...>
Sent: Thursday, January 02, 2003 7:29 PM
Subject: [Fault-injection-developer] [RFC] command in '/sys/triggers/ctl' is changed
> Based on suggestion from Kevin, I found fi_core is better to attach
> trigger with interceptors by *name*. So I'd like to change the ctl command
> as following
> echo "add <trigger_name> <interceptor_type> .... " > /sys/triggers/ctl
> ||
> \/
> echo "add <trigger_name> <interceptor_name> .... " > /sys/triggers/ctl
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
|
