You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Signature event selectors currently serve de-facto as a "event dependency" mechanism similar to the one in the event definitions. There is a need to allow signatures to define selectors which do not automatically load the selected event (for example signatures which consume various optional signatures).
Solution
Option 1 - Discarded
Event dependencies have a required flag which indicates wether tracee should fail when the event is not available. A similar flag can be used here. In the context of signatures this will indicate that the signature can function without input from the selected event.
Option 2 - Selector Semantics Expansion
This cannot use the same semantics as required because required implies the necessary loading of the dependent. The semantics implied by this requirements are a "class of events which stream", somewhat similar to the selector semantics already existing. This implies to me that selector semantics should be expanded and fit for use also in derived events.
For example in our known case the particular selector required is "severity". This implies that selectors should in a sense just be context filters...
The text was updated successfully, but these errors were encountered:
Requirement
Signature event selectors currently serve de-facto as a "event dependency" mechanism similar to the one in the event definitions. There is a need to allow signatures to define selectors which do not automatically load the selected event (for example signatures which consume various optional signatures).
Solution
Option 1 - Discarded
Event dependencies have arequired
flag which indicates wether tracee should fail when the event is not available. A similar flag can be used here. In the context of signatures this will indicate that the signature can function without input from the selected event.Option 2 - Selector Semantics Expansion
This cannot use the same semantics as required because required implies the necessary loading of the dependent. The semantics implied by this requirements are a "class of events which stream", somewhat similar to the selector semantics already existing. This implies to me that selector semantics should be expanded and fit for use also in derived events.
For example in our known case the particular selector required is "severity". This implies that selectors should in a sense just be context filters...
The text was updated successfully, but these errors were encountered: