lkml.org 
[lkml]   [2016]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Joe,
>
> On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <joe@perches.com> 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

\
 
 \ /
  Last update: 2016-03-25 10:01    [W:0.052 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site