Messages in this thread | | | Subject | Re: net/kgdb: Taking another crack at implementing kgdboe | From | Jason Wessel <> | Date | Fri, 21 Feb 2020 21:16:43 -0600 |
| |
On 2/21/20 6:33 PM, Jordan Hand wrote: > Hey folks, > > I have been scouring patches from around 2005-2008 related to kgdboe > (kgdb over ethernet) and I am interested in taking a shot at getting it > into the mainline kernel. > > I found an implementation from Tom Rini in 2005[1] and an out of tree > implementation[2]. > > So I have a couple questions before I dive in: > > 1. Is anyone actively working on this? From lkml archives it appears no > but I thought I'd ask.
I don't believe there is anyone working on this.
> 2. Does anyone have an objection to this feature? From my reading it > seems that the reason it was never merged was due to reliability issues > but I just want to double check that people don't see some larger issue.
I think some of the biggest problems here are what it takes to stop the ethernet hardware, use it for a bit, and then put it back together. The changes to the network stack and the ethernet drivers were fairly invasive to get it work with any degree of reliability.
Long ago, in 2008 I had proposed perhaps using a second dedicated ethernet queue, vs trying to put the driver back into a good state after you have stopped the core kernel execution. I still view this to be the best approach to getting a reliable debugger if you are facing some kind of situation that you must use something that is "in kernel". You really need a way that you can process inputs and outputs safely without using any other function in the kernel except for what is provided in the debug core. This would also give us a more reliable way to have a "netconsole" for dumping ftrace data and oops logs.
> > I don't have 100% of my time to devote to this so it will likely take me > a while but this is something I would like to see in the upstream kernel > so I thought I'd give it a try. > > [1] https://lkml.org/lkml/2005/7/29/321
I definitely have a version from 2014 that is newer than what was posted there, which relies on the netpoll controller part of which has been removed from the mainline kernel. I also have a pile of USB patches which enable the use of KDB with a USB keyboard. Quite a few years have passed by since I tried to submit them to the USB maintainers. It is a similar kind of situation as the ethernet. It is hard to talk to the drivers in a polling state and put them back to a working state when you resume. Stopping is the easy part.
> [2] https://github.com/sysprogs/kgdboe >
This is a much newer project than the implementation from Tom or myself.
Cheers, Jason.
| |