Markus Armbruster writes: > Lluís Vilanova <[email protected]> writes: >> Eric Blake writes: >> >>> On 08/21/2014 11:52 AM, Lluís Vilanova wrote: [...] >>>> +# >>>> +# Since 2.2 >>>> +## >>>> +{ 'command': 'trace-event-set-state', >>>> + 'data': {'name': 'str', 'state': 'bool', '*keepgoing': 'bool'} } >> >>> This only lets me set the state of one name at a time. Oh, unless I'm >>> setting a pattern, and it then sets the state of all names that match >>> that pattern. I'm wondering if you should have 'name':['str'] to allow >>> me to set multiple names/patterns in one go, instead of having to call >>> the command multiple times; but it's probably not worth the complexity. >> >> I agree with the complexity comment. Also, the keepgoing is useful to set >> events >> using a pattern, even if some of them are statically disabled (otherwise it >> gives an error).
> Yes, let's keep this simple. > However, I feel keepgoing is unnecessarily vague. Its purpose is to > enable use of a pattern in the presence of disabled events. I'd prefer > to nail it down to exactly that purpose rather than having it cover > arbitrary, unspecified errors. > A few ideas on how to do that: > * Have a flag to modify the semantics of the pattern: either "match all > events", or "match just disabled and enabled events, not unavailable > events". > * To find out what a trace-event-set-state actually does, you need to > trace-event-get-state the same pattern. We could make > trace-event-set-state return the events it changed, so you never have > to trace-event-get-state, but it's probably not worthwhile. > [...] I've renamed it to "ignore-unavailable" (off by default). Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
