[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8fb50283-cd44-8fb8-9c63-de4c33c9cc5e@windriver.com>
Date: Wed, 6 Dec 2017 16:51:58 -0600
From: Jason Wessel <jason.wessel@...driver.com>
To: Randy Dunlap <rdunlap@...radead.org>,
Daniel Thompson <daniel.thompson@...aro.org>,
Lee Jones <lee.jones@...aro.org>
CC: <kgdb-bugreport@...ts.sourceforge.net>,
Andrew Morton <akpm@...ux-foundation.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [Kgdb-bugreport] [PATCH] MAINTAINERS: kgdb: Replace Jason with
Daniel
On 12/05/2017 10:42 AM, Randy Dunlap wrote:
> On 12/05/2017 06:55 AM, Daniel Thompson wrote:
>> On 05/12/17 14:37, Jason Wessel wrote:
>>> I have a series of 50+ patches for kgdb/kdb/usb which have never been published. I am not saying that we actually need any of those patches, but it would be nice to let the community decide, and we can see if there is anything worth merging into the next cycle or future work with other maintainers. My kernel.org tree stopped working a long time ago, probably from inactivity. I'll see if that can get restored in the next few days, or I'll use my github tree and send the unpublished work to the mailing list as an RFC.
>>
>> I, for one, would be interested to see these.
>
> Me also. I have 3 kdb patches that I just made.
>
>
If you have some patches please do send them along to the list. I have added Daniel as an additional maintainer for when I am not around.
We are open for business again now that my kernel.org tree accepts my tag signing again. It will take some time to go through these unpublished patches to see what is actually relevant, but I'll posting some of them to the mailing reasonably list soon.
Cheers,
Jason.
ps
While on the topic of debuggers... I was thinking it might be interesting to have a gdb-serial stub in an FPGA for debugging the kernel not unlike what was done with the firewire debugger that Andi Kleen worked on long ago. I am not exactly sure what kind of run control options exist there but in terms of accessing memory it would certainly be plausible to access it. One option I know that is plausible for run control is a small kernel interrupt handler perhaps for the run control interface based on the fact you can some FPGAs show up like a PCI device.
While I haven't been directly working in upstream linux in last year or two, I still do plenty of debugging of full systems with simulators, hardware, and now FPGAs too. :-)
Powered by blists - more mailing lists