----- Original Message ----- > This is my first time submitting a patch to a mailing list, so please be > patient with me if I've made any mistakes. Hello Kyle, You've done the right thing. Sorry for the delay -- I'm swamped with post-vacation chores... However, I personally do not maintain the extensions/trace.c file. It was written by Fujitsu, and has passed through a couple of their maintainers since its origination. Currently it's owned by Qiao Nuohan, and with any proposed patch, I would need his ACK to check it in. On the other hand, there was this recent trace.c patch posted and accepted last month: [PATCH] extensions/trace: Fix ftrace_get_event_type_name() https://www.redhat.com/archives/crash-utility/2016-July/msg00000.html Re: [PATCH] extensions/trace: Fix ftrace_get_event_type_name() https://www.redhat.com/archives/crash-utility/2016-July/msg00001.html Re: [PATCH] extensions/trace: Fix ftrace_get_event_type_name() https://www.redhat.com/archives/crash-utility/2016-July/msg00002.html Re: [PATCH] extensions/trace: Fix ftrace_get_event_type_name() https://www.redhat.com/archives/crash-utility/2016-July/msg00003.html In that case, there was no response from Qiao. But since the patch was simple enough, and wouldn't break backwards-compatibility, I went ahead and checked it in. But due to the complexity of this patchset, I'm not comfortable doing that, and I want a review/ACK from Qiao, or if there is still no response from him, from Steve Rostedt, who has offered to take over maintainership of the module in the past. I'm cc'ing everyone directly in hopes of getting a response this time. Thanks, Dave > Since the 3.10 release, the Linux kernel has offered the ability to create > multiple independent ftrace buffers. At present, however, crash is only able to > extract the primary buffer. These patches seek to change that. All of the data > is already collected in the vmcore file; crash just isn't currently > extracting > it. > > I've split this changeset up into two pieces to address this. This first part > shouldn't lead to any change in functionality; it simply refactors the trace > extension so that the global instance is passed around as a parameter rather > than accessing it directly. That facilitates the second part, which locates all > of the available instances and extracts the data from each of them. > > My testing has only included vmcores collected from 32-bit ARM systems, but I > don't believe I have made any assumptions about the architecture in my code. > > Kyle Tomsic (2): > Refactor trace extension to pass trace information as an argument > Add support for multiple ftrace instances to trace extension > > extensions/trace.c | 430 > +++++++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 333 insertions(+), 97 deletions(-) > > -- > 2.9.2 > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
