Re: [PATCH 8/9] Documentation for DTrace USDT probes.

[jose.marchesi@oracle.com (Jose E. Marchesi)]

    
    > +Some @code{SystemTap} probes have an associated semaphore variable;
    > +for instance, this happens automatically if you defined your probe
    > +using a DTrace-style @file{.d} file.  If your probe has a semaphore,
    > +@value{GDBN} will automatically enable it when you specify a
    > +breakpoint using the @samp{-probe-stap} notation.  But, if you put a
    > +breakpoint at a probe's location by some other method (e.g.,
    > +@code{break file:line}), then @value{GDBN} will not automatically set
    > +the semaphore.  @code{DTrace} probes do not support the notion of
    > +semaphores.
    
    The last sentence confused me: you first explain something that seems
    to imply semaphores are part of DTrace probes, but then say that they
    don't support semaphores.  What am I missing?

The paragraph starts explaining that SystemTap probes may have
associated semaphore variables, followed by a short description on how
gdb handles these variables.  That was part of the original
documentation on SystemTap probes.

I just added the last sentence to note that DTrace probes do not support
semaphore variables at all.

I don't see where the confusion is?
    
    > +probe being handled.  Some @code{DTrace} probes can be enabled or
    > +disabled, but @code{SystemTap} probes do not support these notions.
    
    Which "notions"?  If you want to say they cannot be disabled, please
    say so explicitly.

No, I want to say that SystemTap probes do not even support the notion
of being enabled or disabled.  That is not quite the same than saying
that SystemTap probes cannot be disabled: for example some DTrace probes
cannot be disabled because they are always enabled.