On 3/25/16, Jeffrey Merkey <jeffmerkey@xxxxxxxxx> wrote: > On 3/25/16, Jeffrey Merkey <jeffmerkey@xxxxxxxxx> wrote: >> On 3/25/16, Jeffrey Merkey <jeffmerkey@xxxxxxxxx> wrote: >>> 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 >> >> >> In simple terms if you pull mdb as a branch to the x86 tree then I >> will do whatever you ask me to do to integrate it into kdb. You have >> to accept the code as is to show me you are serious, then I will adapt >> it however you ask me to. >> >> Jeff >> > > I went back and checked the code and as it turns out, none of the > patches you nak'd are in the current branch, there are different > patches there now. There are two patches you ignored that are in it, > but no record of a Nak for either of them. > > > Jeff > Signed-Off-By: Jeffrey Merkey <jeffmerkey@xxxxxxxxx> -- 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
