>  To be clear: my proposal is to replace only debug logging (i.e. for
>  developers), not the other logging in general, as the subject line
>  says.  Although I agree that DTrace is not lightweight, I think
>  impact of just adding tracing probes is small.
> -- Hiroki

I believe this would indeed be beneficial for debugging. My main concern
is the way that we would have to attach to probes should we use SDT
provider as it works now. If we were to create probes for each of the
daemons, which we would then run individually, and if I'm not mistaken,
that would spawn 2 times the amount of processes than are currently 
spawned due to each ``dtrace'' call from the command line spawns a process.

Currently, I'm personally leaning towards a different provider, or
perhaps a generalization of some operating principles in the SDT
provider, so that code duplication can be avoided.

Implementing a different provider would allow for a way to automatically
log and fire the probes(this can be done quite easily in the provider).
Additionally, the user could attach to the probes and perform some
different operations in them as well. If we say that the logging level
is 0, we could use a linker set and patch up the daemons to nops, so
that there is no overhead. If we want to log something, we could simply
patch them back in(this could be a sysctl).

If the user wants to log something, one could attach to the probe using
``dtrace'', which would cause the provider to then patch up only that
probe in the daemons, resulting in no overhead in other daemons. The
sole purpose of this is to have a way to toggle logging and avoid
spawning many processes of dtrace in order to log.

The functionality could also be implemented in the way that Adrian was
talking about, we could just say that the log is a debug log, and we
only want to trigger it when a certain flag is set.

Best regards,
Domagoj Stolfa.

Attachment: signature.asc
Description: PGP signature

Reply via email to