Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1364597 > unrolled thread

Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

Started byIngo Molnar <mingo@kernel.org>
First post2016-03-25 09:40 +0100
Last post2016-03-26 02:50 +0100
Articles 8 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [GIT PULL v4.6]  MDB Linux Kernel Debugger x86/x86_64 Ingo Molnar <mingo@kernel.org> - 2016-03-25 09:40 +0100
    Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64 Jeffrey Merkey <jeffmerkey@gmail.com> - 2016-03-25 18:20 +0100
      Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64 Jeffrey Merkey <jeffmerkey@gmail.com> - 2016-03-25 18:30 +0100
        Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64 Jeffrey Merkey <jeffmerkey@gmail.com> - 2016-03-26 00:10 +0100
          Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64 Jeffrey Merkey <jeffmerkey@gmail.com> - 2016-03-26 00:10 +0100
          Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64 Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-26 02:50 +0100
            Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64 Jeffrey Merkey <jeffmerkey@gmail.com> - 2016-03-26 03:00 +0100
    Re: [GIT PULL v4.6]  MDB Linux Kernel Debugger x86/x86_64 Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-26 02:50 +0100

#1364597 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromIngo Molnar <mingo@kernel.org>
Date2016-03-25 09:40 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgvrI-7tD-9@gated-at.bofh.it>
* 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

[toc] | [next] | [standalone]


#1364783 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromJeffrey Merkey <jeffmerkey@gmail.com>
Date2016-03-25 18:20 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgDyX-50o-11@gated-at.bofh.it>
In reply to#1364597
On 3/25/16, Ingo Molnar <mingo@kernel.org> wrote:
>
> * 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
>

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

[toc] | [prev] | [next] | [standalone]


#1364789 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromJeffrey Merkey <jeffmerkey@gmail.com>
Date2016-03-25 18:30 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgDID-55j-19@gated-at.bofh.it>
In reply to#1364783
On 3/25/16, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
> On 3/25/16, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * 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
>>
>
> 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

[toc] | [prev] | [next] | [standalone]


#1364872 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromJeffrey Merkey <jeffmerkey@gmail.com>
Date2016-03-26 00:10 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgJ1D-tn-1@gated-at.bofh.it>
In reply to#1364789
On 3/25/16, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
> On 3/25/16, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
>> On 3/25/16, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * 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
>>>
>>
>> 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

[toc] | [prev] | [next] | [standalone]


#1364878 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromJeffrey Merkey <jeffmerkey@gmail.com>
Date2016-03-26 00:10 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgJ1E-tn-17@gated-at.bofh.it>
In reply to#1364872
On 3/25/16, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
> On 3/25/16, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
>> On 3/25/16, Jeffrey Merkey <jeffmerkey@gmail.com> wrote:
>>> On 3/25/16, Ingo Molnar <mingo@kernel.org> wrote:
>>>>
>>>> * 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
>>>>
>>>
>>> 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@gmail.com>

[toc] | [prev] | [next] | [standalone]


#1364894 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-03-26 02:50 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgLwu-1ZH-9@gated-at.bofh.it>
In reply to#1364872
Hi Jeff,

On Fri, 25 Mar 2016 17:01:27 -0600 Jeffrey Merkey <jeffmerkey@gmail.com> 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

[toc] | [prev] | [next] | [standalone]


#1364896 — Re: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64

FromJeffrey Merkey <jeffmerkey@gmail.com>
Date2016-03-26 03:00 +0100
SubjectRe: [GIT PULL v4.6] MDB Linux Kernel Debugger x86/x86_64
Message-ID<rgLG9-22T-1@gated-at.bofh.it>
In reply to#1364894
On 3/25/16, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Jeff,
>
> On Fri, 25 Mar 2016 17:01:27 -0600 Jeffrey Merkey <jeffmerkey@gmail.com>
> 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
>

I am not going to waste time arguing with the maintainers and chasing
after them.  I have a debugger, it has lots of users and a big
installed base that goes back many years.  So long as they can get it
and use it, things are cool.  Putting it in Linux is actually more of
a pain than just doing what I have been over the years and maintaining
it alongside linux.

Each merge cycle it will be submitted for the linux community, but
like I said, I am not wasting time with folks who are not my customers
and or really not that interested in it.

I already played the bait and switch game with Ingo once before and I
did a lot a work and it was ignored, so he can waste someone else's
time.  Linux is only as good as the people maintaining it.

Jeff

[toc] | [prev] | [next] | [standalone]


#1364895

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-03-26 02:50 +0100
Message-ID<rgLwt-1ZH-5@gated-at.bofh.it>
In reply to#1364597
Hi Ingo,

On Fri, 25 Mar 2016 09:36:21 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> 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 for your input clarifying the situation.
-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web