Messages in this thread | | | Date | Wed, 03 Sep 2014 11:30:16 +0100 | From | Daniel Thompson <> | Subject | Re: [PATCH v11 00/19] arm: KGDB NMI/FIQ support |
| |
On 03/09/14 11:06, Thomas Gleixner wrote: > On Wed, 3 Sep 2014, Daniel Thompson wrote: >> On 03/09/14 00:02, Thomas Gleixner wrote: >>> The use case you are looking for is the most irrelevant of all. Just >>> because KGDB is on some managerial "must have items" checklist does >>> not make it useful. >> >> The FIQ based interactive debugger use case is fairly common on Android, >> especially for Nexus devices (they have an out-of-tree debugger similar >> to kdb for this). >> >> I think it finds favour there because during the development phases >> where the console is unplugged to allow developers to go walkabout live >> with a prototype phone. The interactive debugger is used for >> post-morteming when something breaks. At this stage of development are >> reluctant to expose/consume hardware resources (JTAG pins, RAM, FLASH) >> for JTAG or kexec/kdump post-mortems. > > If things are common and favoured for whatever reasons, that does not > make them a proper solution per se. > > I rather have a kexec debug kernel started if my production/test > kernel explodes than hooking up a lousy debugger via serial, but thats > a matter of taste and reason. > >>> The only relevant use cases of FIQs are the same as those of NMIs on >>> x86: >>> >>> - Watchdog to detect stuck cpus and issue stack traces >> >> Russell put together a quick 'n dirty version of the NMI stack trace >> code based on a subset of my patchset. Based on his feedback, later >> revisions of my patchset are structured to simplify adding this code. > > And I still say, that this is the first use case which should be > provided as it is simple enough, immediately usefull and testable for > everyone. > > So, really what I want to see in the first place is a minimalistic > patch series which > > 1) Implements the core infrastructure for FIQ support > > 2) Converts a single interrupt controller to play with #1 > > 3) Provides the simplest useful use case using #1 > > That's at max 5 patches, which are easy enough to review, and not a > patch series which changes the world and some more in one go.
Ok. I'll look into this.
> We need to get the design and the infrastructure right in the first > place. What I've seen so far is just a complete lack of design. If you > take off your KGDB blinkers, you might notice that yourself.
Good point. I have tried shrinking the patchset previously but I ended up splitting it by sub-system rather than simplifying the use-case.
The guess the effect of shrinking the patchset in this way was more to shrink the pool of likely reviewers than to shrink the size of the problem... Clearly not a good idea (and not intentional on my part).
> As I said before: > >>> KGDB falls into place once you solved the above.
I hope so...
| |