On 3/25/16, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > >> Hi Joe, >> >> On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <joe@xxxxxxxxxxx> wrote: >> > >> > On Mon, 2016-03-14 at 17:50 -0600, Jeffrey Merkey wrote: >> > > The following changes since commit >> > > b562e44f507e863c6792946e4e1b1449fbbac85d: >> > > >> > > Linux 4.5 (2016-03-13 21:28:54 -0700) >> > > >> > > are available in the git repository at: >> > > >> > > https://github.com/jeffmerkey/linux.git tags/mdb-v4.5-signed >> > > >> > > for you to fetch changes up to >> > > 2e9c184e1215dca2b4c59c347f40a0986b8e7460: >> > > >> > > Add MDB Debugger to linux v4.5 (2016-03-14 15:17:44 -0600) >> > >> > If Linus doesn't pull this, Stephen, could you please add this >> > tree to -next so it has some testing and validation done? >> >> Well, I really need a request from the ongoing maintainer and also some >> indication of which kernel release (if any) it is likely to be merged >> into ... > > So neither the x86 nor other affected maintainers have acked these changes > or have > agreed to merge it - in fact there are outstanding NAKs against this tree, > which > were not mentioned in the pull request. > > Here's one of the objections by me: > > https://lkml.org/lkml/2016/1/29/64 > > ... which technical objections were replied to by Jeff Merkey by accusing me > of > trolling: > > "You were not included on the post since you are not a maintainer of > watchdog.c > so I am confused as to why you are nacking and trolling me on something > not in > your area." > > https://lkml.org/lkml/2016/1/29/397 > > So this tree is very far from being ready and I'm not convinced we want to > merge > it in its current form. If we merge bits of it then we want to merge it via > the > x86 tree, not a separate tree. > > In fact I also have more fundamental objections as well, such as the > question of > unnecessary code duplication: this new MDB debugger overlaps in > functionality with > the already in-tree kgdb+KDB live kernel debugger approach: > > I don't think we want to see two overlapping solutions in this area, both of > which > are inferior in their own ways. If then the KDB frontend should be improved: > > features such as disassembler output, more commands and usability > improvements > that can and should be added to the KDB front-end instead. I see nothing in > this > patch that couldn't be added to KDB/KGDB. > > All in one, I'd much rather like to see a gradual set of improvement patches > to > KDB, to improve live kernel debugging, than this kind of monolithic, arch > dependent duplication of functionality. > > Thanks, > > Ingo > Hi Ingo, Adding the disassembler to kgb/kgdb would not be all that straightforward. the architecture of kgdb/kdb does not support it -- it would be significant rewrite of kdb -- in fact, it would have to be completely restructured . There are also as you point out some patches in the debugger you nacked. but removing these is easy. I also would have to go to whomever is maintaining kdb and to be honest, I am not all that interested in doing a bunch of work only to have it rejected or ignored, so the "bait and switch" game of saying "Please do X for us and we'll think about adding Y" isn't something I am going to waste my time on. Linux has more than one file system, more than one ethernet card driver, so there is no reason it can have more than one debugger. Kdb locks up a lot due to the design of it's smp roundup code for stoping processors, it's a different design totally. If you want me to do these things I would need free reign and to be honest, kdb is nowhere near as complete as mdb is. All that being said if you want me to do as you ask then you need to show me that you are serious about taking work I do for these areas. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
