MDB Linux Kernel Debugger x86/x86_64

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)

Quoted 6 lines · Jeffrey Merkey

The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:

  Linux 4.5 (2016-03-13 21:28:54 -0700)

are available in the git repository at:

Quoted 5 lines

  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?

Hi Joe,

Quoted 11 lines · On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <[email protected]> wrote:

Quoted 9 lines · Jeffrey Merkey

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

Quoted 7 lines

Quoted 4 lines

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 ...

As a general rule, I do not add trees to linux-next during the merge window (there have been some special cases when something was going in during that merge window).

I do note that the single commit in that tag has no Signed-off-by, Reviewed-by or Acked-by tags at all. As such I can't see Linus merging it as is. The commit message also has no detail at all. It is also based on v4.5 which was only released yesterday.
--
Cheers,
Stephen Rothwell

I was sure I told git to put a sign-off line. Well, I'll go fix that and amend the commit as signed. Don't know what happened there. Are you supposed to say

git commit -s -a -v -S

I just used

git commit -S -a -v

I'll amend that commit. Folks can review and discuss on this thread.

We don't generally PGP (GPG) sign commits in the kernel tree (so "-S" is not required), just tags. However we always require that anyone who handles a patch adds a Signed-off-by line to the final commit. See Documentation/SubmittingPatches Section 11.

Quoted 4 lines · Stephen Rothwell

We don't generally PGP (GPG) sign commits in the kernel tree (so "-S" is not required), just tags. However we always require that anyone who handles a patch adds a Signed-off-by line to the final commit. See Documentation/SubmittingPatches Section 11.

In general all commits should have a Signed-Off-By line added. Once the git branch gets merged, it's hard to tell what is the final commit and what isn't, and in general different commits will have different people needing to vouch for the origins for the contents of that commit.

Cheers,

- Ted

Quoted 6 lines · Theodore Ts'o

Quoted 4 lines · Stephen Rothwell

We don't generally PGP (GPG) sign commits in the kernel tree (so "-S" is not required), just tags. However we always require that anyone who handles a patch adds a Signed-off-by line to the final commit. See Documentation/SubmittingPatches Section 11.

Quoted 10 lines

In general all commits should have a Signed-Off-By line added. Once the git branch gets merged, it's hard to tell what is the final commit and what isn't, and in general different commits will have different people needing to vouch for the origins for the contents of that commit.

Cheers,

- Ted

Hi Ted,

I will repost this pull request with a signed-off by line for Linus to
consider. I am not certain who all should be included in the review
and I have to be careful how many email recipients I copy. I will
post to the folks Joe Perches copied.

Jeff

Quoted 3 lines · Jeffrey Merkey

Quoted 2 lines · Theodore Ts'o

Quoted 1 line · Stephen Rothwell

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

We don't generally PGP (GPG) sign commits in the kernel tree (so "-S" is not required), just tags.  However we always require that anyone who handles a patch adds a Signed-off-by line to the final commit.  See Documentation/SubmittingPatches Section 11.

In general all commits should have a Signed-Off-By line added.  Once the git branch gets merged, it's hard to tell what is the final commit and what isn't, and in general different commits will have different people needing to vouch for the origins for the contents of that commit.

Quoted 4 lines

I will repost this pull request with a signed-off by line for Linus to consider.    I am not certain who all should be included in the review and I have to be careful how many email recipients I copy.   I will post to the folks Joe Perches copied.

Well, Joe updated checkpatch.pl so now there are some more areas of cleanup I need to do on the code to remove unsigned casts and replace them with unsigned int.  I will resubmit at the next merge window for 4.7.  Have not heard a word from Linus about this, Hey Linus, please don't lion-us by throwing us to the lions.  :-)

Quoted 10 lines · Jeffrey Merkey

Quoted 9 lines · Jeffrey Merkey

Quoted 8 lines · Theodore Ts'o

Quoted 7 lines · Stephen Rothwell

We don't generally PGP (GPG) sign commits in the kernel tree (so "-S"
is not required), just tags. However we always require that anyone who
handles a patch adds a Signed-off-by line to the final commit. See Documentation/SubmittingPatches Section 11.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

In general all commits should have a Signed-Off-By line added. Once the git branch gets merged, it's hard to tell what is the final commit
and what isn't, and in general different commits will have different people needing to vouch for the origins for the contents of that commit.

[]

Quoted 4 lines

Quoted 4 lines

I will repost this pull request with a signed-off by line for Linus to
consider. I am not certain who all should be included in the review
and I have to be careful how many email recipients I copy. I will
post to the folks Joe Perches copied.

[]

Quoted 5 lines

Well, Joe updated checkpatch.pl so now there are some more areas of cleanup I need to do on the code to remove unsigned casts and replace them with unsigned int. I will resubmit at the next merge window for 4.7. Have not heard a word from Linus about this, Hey Linus, please don't lion-us by throwing us to the lions. :-)

I rather doubt Linus is going to pull this code during this merge window.

I think you should try to get this into -next immediately after this current merge window closes in a 10 or so days.

I think you don't have to do random cleanups just to satisfy checkpatch. Get the code in -next and then cleanup stuff as you see fit. There will then be individual commit changelogs for the mostly whitespace changes that checkpatch might point out.

Hi Joe,

Quoted 12 lines · On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <[email protected]> wrote:

Quoted 10 lines · Jeffrey Merkey

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:

Quoted 4 lines

Quoted 1 line

  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 ...

Quoted 17 lines · Stephen Rothwell

Hi Joe,

Quoted 14 lines · On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <[email protected]> wrote:

Quoted 12 lines · Jeffrey Merkey

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:

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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

Quoted 88 lines · Ingo Molnar

Quoted 17 lines · Stephen Rothwell

Hi Joe,

Quoted 14 lines · On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <[email protected]> wrote:

Quoted 12 lines · Jeffrey Merkey

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:

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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.

Quoted 4 lines

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

Quoted 116 lines · Jeffrey Merkey

Quoted 91 lines · Ingo Molnar

Quoted 17 lines · Stephen Rothwell

Hi Joe,

Quoted 14 lines · On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <[email protected]> wrote:

Quoted 12 lines · Jeffrey Merkey

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:

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 129 lines · Jeffrey Merkey

Quoted 119 lines · Jeffrey Merkey

Quoted 94 lines · Ingo Molnar

Quoted 20 lines · Stephen Rothwell

Hi Joe,

Quoted 16 lines · On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches <[email protected]> wrote:

Quoted 13 lines · Jeffrey Merkey

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)

Quoted 7 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 7 lines

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

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.

Hi Jeff,

Quoted 5 lines · On Fri, 25 Mar 2016 17:01:27 -0600 Jeffrey Merkey <[email protected]> wrote:

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.

OK, so one obvious problem is that the tree you want merged has a single patch in it and the diffstat looks like this:

 Documentation/sysrq.txt                    |    2 +-
 MAINTAINERS                                |    6 +
 arch/x86/include/asm/bug.h                 |    9 +-
 arch/x86/include/uapi/asm/debugreg.h       |    1 +
 arch/x86/kernel/Makefile                   |    1 +
 arch/x86/kernel/apic/io_apic.c             |    2 +
 arch/x86/kernel/debug/Makefile             |    3 +
 arch/x86/kernel/debug/mdb/Makefile         |    6 +
 arch/x86/kernel/debug/mdb/Makefile.local   |  106 +
 arch/x86/kernel/debug/mdb/mdb-base.c       | 3293 +++++++++++++
 arch/x86/kernel/debug/mdb/mdb-base.h       |  447 ++
 arch/x86/kernel/debug/mdb/mdb-ia-apic.c    |  243 +
 arch/x86/kernel/debug/mdb/mdb-ia-proc.h    |  819 ++++
 arch/x86/kernel/debug/mdb/mdb-ia-support.c | 5342 +++++++++++++++++++++
 arch/x86/kernel/debug/mdb/mdb-ia-support.h |   76 +
 arch/x86/kernel/debug/mdb/mdb-ia.c         | 6887
++++++++++++++++++++++++++++
 arch/x86/kernel/debug/mdb/mdb-ia.h         |  209 +
 arch/x86/kernel/debug/mdb/mdb-keyboard.h   |  127 +
 arch/x86/kernel/debug/mdb/mdb-list.c       |  534 +++
 arch/x86/kernel/debug/mdb/mdb-list.h       |   96 +
 arch/x86/kernel/debug/mdb/mdb-logic.c      | 2118 +++++++++
 arch/x86/kernel/debug/mdb/mdb-main.c       |  786 ++++
 arch/x86/kernel/debug/mdb/mdb-os.c         | 1474 ++++++
 arch/x86/kernel/debug/mdb/mdb-os.h         |  141 +
 arch/x86/kernel/debug/mdb/mdb-proc.h       |  179 +
 arch/x86/kernel/debug/mdb/mdb.h            |   40 +
 arch/x86/kernel/dumpstack_32.c             |    6 +-
 arch/x86/kernel/dumpstack_64.c             |   18 +
 arch/x86/kernel/hw_breakpoint.c            |   69 +-
 arch/x86/kernel/reboot.c                   |    1 +
 arch/x86/kernel/traps.c                    |   14 +
 drivers/tty/vt/vt.c                        |    4 +
 include/asm-generic/bug.h                  |    4 +
 include/linux/console.h                    |    4 +
 kernel/debug/kdb/kdb_debugger.c            |    2 +-
 kernel/events/hw_breakpoint.c              |    2 +
 kernel/extable.c                           |    1 +
 kernel/kallsyms.c                          |   45 +
 kernel/module.c                            |   43 +
 kernel/rcu/tree.c                          |    1 +
 kernel/sched/core.c                        |   13 +-
 kernel/time/clocksource.c                  |    1 +
 kernel/watchdog.c                          |   17 +-
 lib/Kconfig.debug                          |   66 +
 44 files changed, 23240 insertions(+), 18 deletions(-)

Having it in that form makes it pretty hard for anyone to review ...

If you have a set if incremental patches, maybe you should post those instead.

I am afraid that if the maintainers affected by this code will not merge it, I cannot justify putting it in linux-next myself. --
Cheers,
Stephen Rothwell

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.