On Tue, 19 Sep 2006 10:08:17 +0100 David Howells <[EMAIL PROTECTED]> 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) - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
