>On 2002.05.30 Jeff Garzik wrote:> >>>The basic thing to remember is that "generic_foo" or "cpu_intel_foo" >>options should very rarely, if ever, appear in the config.in or sources. >>We simply want to use the generic or cpu-specific user selection to >>determine (a) compiler flags, (b) CONFIG_xxx symbols for specific CPU >>features and optimizations, [like CONFIG_X86_F00F_BUG] and maybe (c) >>enable and disable CPU-specific drivers. (c) will be a special case, >>since very few drivers should require a specific CPU type... but some >>drivers simply don't work on 386.>>>> >>>>Grep on the tree showed this:>>drivers/char/serial.c:>>#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))>#define SERIAL_INLINE>#endif>>include/asm-i386/processor.h:>>/* Prefetch instructions for Pentium III and AMD Athlon */>#ifdef CONFIG_MPENTIUMIII>>#define ARCH_HAS_PREFETCH> >

ARCH_HAS_foo are feature symbols, just like CONFIG_X86_F00F_BUG, so those are fine. They're just cross-architecture, but perform the same task: feature dis/enabling. For the serial example, you'd just need to make sure the net effect of the code is the same, both before and after an x86 config.in cleanup.