Message-ID: <5406EDB8.8080401@linaro.org>
Date:	Wed, 03 Sep 2014 11:30:16 +0100
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Russell King <linux@....linux.org.uk>,
	linaro-kernel@...ts.linaro.org,
	Catalin Marinas <catalin.marinas@....com>, patches@...aro.org,
	kgdb-bugreport@...ts.sourceforge.net,
	Nicolas Pitre <nico@...aro.org>, linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Fabio Estevam <festevam@...il.com>,
	Colin Cross <ccross@...roid.com>, kernel-team@...roid.com,
	Dave Martin <Dave.Martin@....com>,
	linux-arm-kernel@...ts.infradead.org
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...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists