Daniel P Berrange writes:
> On Mon, Nov 08, 2010 at 04:55:10PM +0100, Lluís wrote:
>> In any case, there might appear other events that could have performance
>> implications, although I understand the ease of usage of having all
>> trace events available by default.
> Ok, I agree that if we have
On Mon, Nov 08, 2010 at 04:55:10PM +0100, Lluís wrote:
> Daniel P Berrange writes:
>
> > On Mon, Nov 08, 2010 at 03:42:15PM +0100, Lluís wrote:
> >> On the current implementation, the "disable" keyword in "trace-events"
> >> has different semantics, depending on the backend:
> >>
> >> * nop:
Daniel P Berrange writes:
> On Mon, Nov 08, 2010 at 03:42:15PM +0100, Lluís wrote:
>> On the current implementation, the "disable" keyword in "trace-events"
>> has different semantics, depending on the backend:
>>
>> * nop: ignored (not a problem)
>> * simple : enables tracing, but sets dynam
On Mon, Nov 08, 2010 at 03:42:15PM +0100, Lluís wrote:
> On the current implementation, the "disable" keyword in "trace-events"
> has different semantics, depending on the backend:
>
> * nop: ignored (not a problem)
> * simple : enables tracing, but sets dynamic state to disable
> * ust: d
On the current implementation, the "disable" keyword in "trace-events"
has different semantics, depending on the backend:
* nop: ignored (not a problem)
* simple : enables tracing, but sets dynamic state to disable
* ust: disables tracing (uses nop backend)
* dtrace : same as simple
Would
