[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzH_-6FuwTF1GVDzLK+7c0MGLsLdPFjzzwU78GVUEMbBw@mail.gmail.com>
Date: Fri, 16 Nov 2012 07:32:01 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mel Gorman <mgorman@...e.de>
Cc: Rik van Riel <riel@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrea Arcangeli <aarcange@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
Johannes Weiner <hannes@...xchg.org>,
Hugh Dickins <hughd@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/43] mm: numa: Make pte_numa() and pmd_numa() a generic implementation
On Fri, Nov 16, 2012 at 6:41 AM, Mel Gorman <mgorman@...e.de> wrote:
>
> I would have preferred asm-generic/pgtable.h myself and use
> __HAVE_ARCH_whatever tricks
PLEASE NO!
Dammit, why is this disease still so prevalent, and why do people
continue to do this crap?
__HAVE_ARCH_xyzzy is a f*cking retarded thing to do, and that's
actually an insult to retarded people.
Use either:
- Kconfig entries for bigger features where that makes sense, and
using the Kconfig files allows you to use the Kconfig logic for things
(ie there are dependencies etc, so you can avoid having to have
complicated conditionals in the #ifdef's, and instead introduce them
as rules in Kconfig files).
- the SAME F*CKING NAME for the #ifdef, not some totally different
namespace with __HAVE_ARCH_xyzzy crap.
So if your architecture wants to override one (or more) of the
pte_*numa() functions, just make it do so. And do it with
static inline pmd_t pmd_mknuma(pmd_t pmd)
{
pmd = pmd_set_flags(pmd, _PAGE_NUMA);
return pmd_clear_flags(pmd, _PAGE_PRESENT);
}
#define pmd_mknuma pmd_mknuma
and then you can have the generic code have code like
#ifndef pmd_mknuma
.. generic version goes here ..
#endif
and the advantage is two-fold:
- none of the "let's make up another name to test for this"
- "git grep" actually _works_, and the end results make sense, and
you can clearly see the logic of where things are declared, and which
one is used.
The __ARCH_HAVE_xyzzy (and some places call it __HAVE_ARCH_xyzzy)
thing is a disease.
That said, the __weak thing works too (and greps fine, as long as you
use the proper K&R C format, not the idiotic "let's put the name of
the function on a different line than the type of the function"
format), it just doesn't allow inlining.
In this case, I suspect the inlined function is generally a single
instruction, is it not? In which case I really do think that inlining
makes sense.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists