Re: [PATCH 5/7] Alter get_order() so that it can make use of ilog2() on a constant [try #3]

[Christoph Hellwig <hch@infradead.org>]

On Tue, Sep 19, 2006 at 08:03:24AM -0700, Andrew Morton wrote:
> On Tue, 19 Sep 2006 10:08:17 +0100
> David Howells <dhowells@redhat.com> wrote:
> 
> > > I didn't pursue it further, because sprinkling ARCH_HAS_FOO things into
> > > bitops.h(!) is all rather hacky.  Better to use CONFIG_* so they're always
> > > visible and one knows where to go to find things.
> > 
> > But (1) they're not config options,
> 
> Well they are, really.  "This architecture has its own get_order()".  It's
> not *user* configurable, but neither is, say CONFIG_GENERIC_HARDIRQS.
> 
> The problem we have with the ARCH_HAS_FOO things is that there's never been
> an include/asm/arch_has_foo.h in which to define them, so stuff gets
> sprinkled all over the place.
> 
> > and (2) there's plenty of precedent for
> > this sort of thing (ARCH_HAS_PREFETCH for example).
> 
> There's precedent both ways.  The advantages of doing it in config are
> 
> a) You know where to go to find it: arch/foo/Kconfig
> 
> b) It's always available, due to forced inclusion of config.h.
> 
> (I think I actually would prefer include/asm/arch_has_foo.h if we had it,
> because it's lighter-weight.  But we don't)

That approach has the problem of not beeing available in the Kconfig
language and thus the Makefiles, so we can't compile files conditionally
on it.   Otherwise I'd say just add asm/config.h, include it automatically
and go ahead.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/