From: Andrew Morton <akpm@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org, mathieu.desnoyers@polymtl.ca,
torvalds@linux-foundation.org, sam@ravnborg.org,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [patch 2/4] Add HAVE_OPROFILE
Date: Fri, 16 Nov 2007 15:10:31 -0800 [thread overview]
Message-ID: <20071116151031.4b18e9e1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071116033207.794556263@polymtl.ca>
On Thu, 15 Nov 2007 22:30:59 -0500
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> Linus:
> On the per-architecture side, I do think it would be better to *not* have
> internal architecture knowledge in a generic file, and as such a line like
>
> depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
>
> really shouldn't exist in a file like kernel/Kconfig.instrumentation.
>
> It would be much better to do
>
> depends on ARCH_SUPPORTS_KPROBES
>
> in that generic file, and then architectures that do support it would just
> have a
>
> bool ARCH_SUPPORTS_KPROBES
> default y
>
> in *their* architecture files. That would seem to be much more logical,
> and is readable both for arch maintainers *and* for people who have no
> clue - and don't care - about which architecture is supposed to support
> which interface...
argh, I merged the previous version. Dropped it again.
> Changelog:
>
> Actually, I know I gave this as the magic incantation, but now that I see
> it, I realize that I should have told you to just use
>
> config ARCH_SUPPORTS_KPROBES
> def_bool y
>
> instead, which is a bit denser.
>
> We seem to use both kinds of syntax for these things, but this is really
> what "def_bool" is there for...
>
> - Use ARCH_HAS_* instead of ARCH_SUPPORTS).
> - Use a select ARCH_HAS_*
>
> - Yet another update :
>
> Moving to HAVE_* now.
Please don't do changelogs this way (ie: provide a wrong changelog plus
erratum).
Just update the changelog so that it is in its final form, thanks.
It's fine to add a note at the bottm describing what changed since the
previous patchset - I'll just trim that away for the final git commit.
next prev parent reply other threads:[~2007-11-16 23:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-16 3:30 [patch 0/4] Instrumentation menu removal (HAVE_* form) Mathieu Desnoyers
2007-11-16 3:30 ` [patch 1/4] Create arch/Kconfig Mathieu Desnoyers
2007-11-16 3:30 ` [patch 2/4] Add HAVE_OPROFILE Mathieu Desnoyers
2007-11-16 23:10 ` Andrew Morton [this message]
2007-11-16 3:31 ` [patch 3/4] Add HAVE_KPROBES Mathieu Desnoyers
2007-11-16 3:31 ` [patch 4/4] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig Mathieu Desnoyers
-- strict thread matches above, loose matches on Subject: below --
2007-12-04 17:43 [patch 0/4] Instrumentation menu removal Mathieu Desnoyers
2007-12-04 17:44 ` [patch 2/4] Add HAVE_OPROFILE Mathieu Desnoyers
2007-12-08 15:32 [patch 0/4] Instrumentation menu removal, against 2.6.24-rc4-mm1 (mmotm) Mathieu Desnoyers
2007-12-08 15:32 ` [patch 2/4] Add HAVE_OPROFILE Mathieu Desnoyers
2007-12-12 5:33 ` Andrew Morton
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=20071116151031.4b18e9e1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=sam@ravnborg.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.