mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Jeffrey Merkey <jeffmerkey@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	dzickus@redhat.com, uobergfe@redhat.com, atomlin@redhat.com,
	mhocko@suse.cz, fweisbec@gmail.com, tj@kernel.org,
	hidehiro.kawai.ez@hitachi.com, cmetcalf@ezchip.com
Subject: Re: [PATCH 01/31] Add hard/soft lockup debugger entry points
Date: Thu, 28 Jan 2016 23:06:30 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1601282257410.3886@nanos> (raw)
In-Reply-To: <CA+ekxPWajQ6ppWYr6SCaMnHn479+WnZpb8dqRvZwJn1EvTshFw@mail.gmail.com>

On Thu, 28 Jan 2016, Jeffrey Merkey wrote:
> On 1/28/16, Thomas Gleixner <tglx@linutronix.de> wrote:
> If you don't get it Thomas, I don't know what else to say.  Right now
> the only debugger that provides disassembly on a single running live
> Linux system is the one I use unless you want to use a serial
> connection with kgdb.  All you are convincing me of is that you don't
> use a debugger or sit around looking at dissassembly all day long on
> live linux systems looking for bugs or you would understand why this
> is so helpful.  So I totally understand why you don't get this.

It does not matter a whit whether I use a debugger or not. It matters that I
can find out without too much hassle where this stupid address is where I want
to set my breakpoint. It's not rocket science.
 
> Think of it like git.  Before git was around, everything was done with
> manual patches.  Now we have git, and everything can be automated.
> Same thing here.  Why do I want to grep around looking for a bug when
> I can have linux find it for me.

Using the proper tools you can figure that address out fully automated without
rumaging in disassembly.

You obviously completely ignored this part of my reply:

> > If we follow your argumentation we need another gazillion of conditional
> > breakpoints in the kernel.

Thanks,

	tglx

  reply	other threads:[~2016-01-28 22:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 19:46 Jeffrey Merkey
2016-01-28 19:56 ` Thomas Gleixner
2016-01-28 20:08   ` Jeffrey Merkey
2016-01-28 20:48     ` Thomas Gleixner
2016-01-28 20:58       ` Jeffrey Merkey
2016-01-28 22:06         ` Thomas Gleixner [this message]
2016-01-28 22:22           ` Jeffrey Merkey
2016-01-29  8:16         ` Ingo Molnar
2016-01-29 16:26           ` Jeffrey Merkey
2016-01-29 16:34           ` Jeffrey Merkey
2016-01-29 17:19             ` Jeffrey Merkey
2016-01-30  2:43           ` Jeffrey Merkey
2016-01-28 20:35 ` kbuild test robot
2016-01-28 20:41 ` Chris Metcalf
2016-01-28 20:48   ` Jeffrey Merkey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1601282257410.3886@nanos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@redhat.com \
    --cc=cmetcalf@ezchip.com \
    --cc=dzickus@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=jeffmerkey@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=tj@kernel.org \
    --cc=uobergfe@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®