> On 11/10/2016 02:47 PM, Frank Filz wrote: > >> On 11/08/2016 05:47 PM, Frank Filz wrote: > >>> 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. > >> > >> Thread ID is already included in Ganesha log messages. > > > > But not in the part that goes to LTTng, at least the way I understand > > it, maybe I misread something... Actually, we need to clean up that > > code that decides what to put in the header for different log > > facilities, if we move LTTng to being just another log facility, then > > I would be very inclined to change how the headers are handled... > > > > The entire formatted message (including thread ID) is passed to LTTNG. > It would need parsing, but it's there.
No, it isn't.... So the log message is built in the thread local variable log_buffer. There is a struct display_buffer that describes that string buffer. There are three elements of a log message: Header Component Message The header (including thread id, process name, pid, timestamp, etc.) is written at the beginning of log_buffer (which is thus log_buf.b_start). Then the variable compstr is set to the current position in log_buffer and the component (and level, function, file, and line) is written. Then the variable message is set to the current position in log_buffer and the message itself is written The LTTng tracepoint is called passing component, level, function, file, line, and message. Anything that goes into the header is not passed to LTTng tracepoint. Instead of that goofy way of splitting up the string (sorry, really stupid coding on my part...), it would be better to allow each facility to specify which parts it wants (syslog and LTTng presumable for sure don't need timestamp, process name, and pid, I wonder if we actually want thread name in syslog, I need to revisit why I left threadname out of syslog). I also see a bug... log_buf uses sizeof(log_buffer), and then log_to_file appends a newline... The code was attempting to do sprint stuff once even if multiple facilities were enabled, this needs to be revisited so it's done better. 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 Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
