MIME-Version: 1.0
In-Reply-To: <1475548970.1923.5.camel@perches.com>
References: <20161004001720.GA351@166-70-60-63.utopia.xmission.net>
 <1475545624.1923.3.camel@perches.com> <20161004132927.3ff5d0ce@canb.auug.org.au>
 <1475548970.1923.5.camel@perches.com>
From: Jeffrey Merkey <jeffmerkey@gmail.com>
Date: Mon, 3 Oct 2016 20:54:11 -0600
Message-ID: <CA+ekxPVQyg1GgP4eY2=YoOahwmh6KHfcmkLj6ftN7fOifTB3KA@mail.gmail.com>
Subject: Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)
To: Joe Perches <joe@perches.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, linux-kernel@vger.kernel.org,
        Ingo Molnar <mingo@kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3615
Lines: 92

On 10/3/16, Joe Perches <joe@perches.com> wrote:
>
> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>> Hi Joe,
>
> Hi Stephen.
>
>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches <joe@perches.com> wrote:
>> >
>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>> > > The following changes since commit
>> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>> > >
>> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
>> > >
>> > > are available in the git repository at:
>> > >
>> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
>> > >
>> > > for you to fetch changes up to
>> > > 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
>> > >
>> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)
>> >
>> >
>> > Stephen, can this tree be added to -next to get some
>> > exposure for the next cycle?
>>
>>
>> I don't add trees during the merge window (unless they contain stuff
>> for the current merge window and, even then, only rarely).  Also, I
>> only take requests from the maintainer/owner of the tree.
>
> No worries, it's really a request for Jeff who doesn't seem
> to know the process very well.
>
> Jeff, you really should get this into -next before sending a
> pull request to Linus for this large bit of code.
>
>> Has there been much recent discussion/review/testing of this tree?
>
> Not to my knowledge for about 6 months now.
>
>> Is it likely that Linus will merge it?  (Just asking, I haven't been
>> following it.)
>
> Dunno.  I'd guess it will _not_ be merged without some time
> in -next and a compelling reason to use it.
>
>

Hi Joe,
Hi Stephen,

I put it out as a pull request so the kbuild test robot can build it
against all sort of configs to make certain it runs across all
i386/x86_64 configs.  If I recall correctly, Ingo Molnar stated he
would be interested in mdb being chopped up into pieces and possibly
integrated into kdb, since MDB has a very good disassembler and
conditional breakpoints which kdb lacks, if I understood what he said
last linux release when this came up.

Since I produce mdb for mostly my own internal use, I have not done
this integration work as of yet as I have been more a user of MDB than
the developer of late.  That's not to say someone else could do what
Ingo suggested, and I have looked over KDB but to be honest, it would
require a whole lot of non-intrusive changes to kdb to pull it off --
not impossible but where I left it with Ingo is he would need to ask
and be specific about what changes or sections he would want in KDB.
Without specific guidance from him, I hesitate to work on it -- in
other words he needs to ask me exactly what he expects to be done
here.   kdb is a very unstable tool from what limited testing I have
done and it's processor roundup for SMP systems is a very different
approach from mdb and is prone to crashes and lockups (particularly
when you are servicing multiple NMI interrupts and more then one of
the processors ends up in the INT1 exception handler).

MDB's plus to Linux is a working deferenced disassembler which kdb
lacks.  Ingo did not like the fact the MDB is monolithic if I read
what he said correctly, and I can see his point, however, debuggers
are always tightly coupled with the underlying arch.  kgdb is
interesting but is not a standalone debugger, requires two boxes, and
uses a cumbersome command syntax.

That being said, Ingo will need to ask me to do the work then be a
little more forthright about his interest -- if any -- and provide
some guidance.  If Linus wants to pull it be my guest.  It's always
out there for him or anyone else who needs it.

:-)

Jeff