On Thu, Aug 18, 2016 at 08:05:40AM -0500, Josh Poimboeuf wrote: > > The x86 stack dump code is a bit of a mess. dump_trace() uses > callbacks, and each user of it seems to have slightly different > requirements, so there are several slightly different callbacks floating > around. > > Also there are some upcoming features which will require more changes to > the stack dump code: reliable stack detection for live patching, > hardened user copy, and the DWARF unwinder. Each of those features > would at least need more callbacks and/or callback interfaces, resulting > in a much bigger mess than what we have today. > > Before doing all that, we should try to clean things up and replace > dump_trace() with something cleaner and more flexible. > > The new unwinder is a simple state machine which was heavily inspired by > a suggestion from Andy Lutomirski: > > > https://lkml.kernel.org/r/CALCETrUbNTqaM2LRyXGRx=kVLRPeY5A3Pc6k4TtQxF320rUT=w...@mail.gmail.com > > It's also similar to the libunwind API: > > http://www.nongnu.org/libunwind/man/libunwind(3).html > > Some if its advantages: > > - simplicity: no more callback sprawl and less code duplication. > > - flexibility: allows the caller to stop and inspect the stack state at > each step in the unwinding process. > > - modularity: the unwinder code, console stack dump code, and stack > metadata analysis code are all better separated so that changing one > of them shouldn't have much of an impact on any of the others. > > ---- > > Josh Poimboeuf (57):
I am personally unable to review a 57 patches series. Any chance you could split it into self-contained steps? In general doing so increase the chances for reviews, accelerate merging, improve maintainance... Thanks.
