public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Johannes Weiner" <hannes@saeurebad.de>,
	"Arjan van de Ven" <arjan@linux.intel.com>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] softlockup: show irqtrace
Date: Wed, 25 Jun 2008 19:11:11 +0200	[thread overview]
Message-ID: <19f34abd0806251011t6732e64dj43f4a67ec3de33ce@mail.gmail.com> (raw)
In-Reply-To: <20080625160016.GA24967@elte.hu>

On 6/25/08, Ingo Molnar <mingo@elte.hu> wrote:
> > (Compile tested on allyesconfig, allnoconfig, allnoconfig + softlockup
> > debugging.)
>
> hm, that must have taken quite some time to do on your desktop, right?

Hm, no. I admit to having improved the process of compilation
somewhat; I compiled only the affected files, or in case a CONFIG
prevents a file from being built, the complete parent directory. I
find that this works well in practice; the compiler usually warns
about implicit declarations (which would otherwise show up as linker
errors), so there is no need to link everything. (Sadly, this is not
true when declarations are provided regardless of definition -- I
think this is actually a case against putting declarations outside
#ifdefs.)

> FYI, there's no mandatory need to go through that buerocratic testing
> hassle with patches submitted to -tip - especially with small patches
> that look obvious and have a high chance of being right. We do non-stop
> allyes/allno/allmod+randconfig 64-bit/32-bit build and boot testing for
> every single patch added to the repository.
>
> Building, booting and testing it in the environment where you expect it
> to be used primarily should be more than enough.

Well, it's still somewhat emberassing to submit patches that don't compile :-)

This patch was also a typical error scenario; I introduce the call of
a function which requires the inclusion of a new header, one which
seemingly depends on a particular config option (lockdep). So I simply
wanted to be sure myself -- and then I might as well put it in the
e-mail. That also implicitly means that I did not boot test it at all.
(Because, yeah, what it actually DOES should be fairly obvious.)

Thanks, though! It's really nice to know the world's not coming to an
end because of a broken patch ;-)


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

  reply	other threads:[~2008-06-25 17:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25  7:13 [PATCH] softlockup: show irqtrace Vegard Nossum
2008-06-25 16:00 ` Ingo Molnar
2008-06-25 17:11   ` Vegard Nossum [this message]
2008-06-25 21:15 ` Johannes Weiner

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=19f34abd0806251011t6732e64dj43f4a67ec3de33ce@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@linux.intel.com \
    --cc=hannes@saeurebad.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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