We discussed LTTng in today's call, and looking at the code I have some thoughts:
1. Ganesha currently has no way to disable all log facilities, so with LTTng, we would still be logging to a file or syslog or something. 2. One option is to make LTTng a log facility, though to get the "right" stuff in it, we would need to enhance the options a log facility can specify 3. Another option is to specify a NULL facility that does nothing (so the existing LTTng tracepoint function just does it's work 4. I'm wondering if LTTng does anything to associate a log message with a particular thread. For debugging, it is very handy to know which thread emitted a particular message. I assume it would be easy to add the thread name as another parameter to tracepoint, but there might be a better way to handle it (it IS nice to have the threads by name, but most of the time they're worker threads, so if LTTng already logs pthread_self, that might be enough. 5. If LTTng can handle it, and the post trace filtering is good enough, LTTng could work with -N NIV_FULL_DEBUG, otherwise, LTTng DOES only trace log messages that are enabled. This may be a good thing (and will be the case even if we made LTTng a log facility). I need to set up LTTng an play with it... Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
