[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1202770566.12383.59.camel@cinder.waste.org>
Date: Mon, 11 Feb 2008 16:56:06 -0600
From: Matt Mackall <mpm@...enic.com>
To: Michael Opdenacker <michael-lists@...e-electrons.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Linux-tiny@...enic.com
Subject: Re: [PATCH] x86 (Linux Tiny): configure out support for some
processors
On Mon, 2008-02-11 at 23:42 +0100, Michael Opdenacker wrote:
> /* Specific CPU type init functions */
> -int intel_cpu_init(void);
> -int amd_init_cpu(void);
> -int cyrix_init_cpu(void);
> -int nsc_init_cpu(void);
> -int centaur_init_cpu(void);
> -int transmeta_init_cpu(void);
> -int nexgen_init_cpu(void);
> -int umc_init_cpu(void);
> +
> +#ifdef CONFIG_CPU_SUP_INTEL
> +int __cpuinit __ppro_with_ram_bug(void);
> +static inline int __cpuinit ppro_with_ram_bug(void)
> +{
> + return __ppro_with_ram_bug();
> +}
I know Ingo said to do this, but I think he was flat-out wrong. If the
tradeoff is between having a dozen ifdefs contained in a single function
in one .c file vs wrapping a dozen function in a .h file, I say stick
them in the .c file.
Best would be to have no ifdefs and do it all with linker magic, of
course. But that's trickier.
Now the patch is 90% fiddling with wrappers and it's impossible to find
the interesting bits anymore..
--
Mathematics is the supreme nostalgia of our time.
--
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