Hello, > 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.
signature.asc
Description: PGP signature
