Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On Mon, 2008-02-11 at 16:54 -0800, H. Peter Anvin wrote: > Matt Mackall wrote: > > On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote: > >> Matt Mackall wrote: > >>> Best would be to have no ifdefs and do it all with linker magic, of > >>> course. But that's trickier. > >>> > >> I concur with this, definitely. > > > > Ok, so let's come up with a plan. We can: > > > > a) use weak symbols, ala cond_syscall > > b) use a special section > > c) use early_init code (is it early enough?) > > c) have some sort of registration list > > > > Having a generic cond_call of some sort might be nice for this sort of > > thing. > > > > c) is out, because this has to be executed after the early generic code > and before the late generic code. > > b) would be my first choice, and yes, it would be a good thing to have a > generalized mechanism for this. For the registrant, it's pretty easy: > just add a macro that adds a pointer to a named section. We then need a > way to get the base address and length of each such section in order to > be able to execute each function in sequence. I like the idea of making a generalized hook section. But this is a bit burdensome for Michael's little patch (unless you have time to whip something up) so I think we should probably explore it separately. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
Matt Mackall wrote: On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote: Matt Mackall wrote: Best would be to have no ifdefs and do it all with linker magic, of course. But that's trickier. I concur with this, definitely. Ok, so let's come up with a plan. We can: a) use weak symbols, ala cond_syscall b) use a special section c) use early_init code (is it early enough?) c) have some sort of registration list Having a generic cond_call of some sort might be nice for this sort of thing. c) is out, because this has to be executed after the early generic code and before the late generic code. b) would be my first choice, and yes, it would be a good thing to have a generalized mechanism for this. For the registrant, it's pretty easy: just add a macro that adds a pointer to a named section. We then need a way to get the base address and length of each such section in order to be able to execute each function in sequence. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote: > Matt Mackall wrote: > > > > Best would be to have no ifdefs and do it all with linker magic, of > > course. But that's trickier. > > > > I concur with this, definitely. Ok, so let's come up with a plan. We can: a) use weak symbols, ala cond_syscall b) use a special section c) use early_init code (is it early enough?) c) have some sort of registration list Having a generic cond_call of some sort might be nice for this sort of thing. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
Michael Opdenacker wrote: Also note that for the sake of convenience and consistency between 32 and 64 bit, I move the declaration of force_mwait from kernel/cpu/amd.c to kernel/setup_32.c (force_mwait is already defined in kernel/setup_64.c). NAK NAK NAK NAK NAK NAK NAK This is the totally wrong thing to do. The CPU initialization stuff should move *into* the CPU directory (unification based on the cleaned-up 32-bit code, not on the 64-bit code which is based on a fork of the pre-cleanup 32-bit code.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
Matt Mackall wrote: Best would be to have no ifdefs and do it all with linker magic, of course. But that's trickier. I concur with this, definitely. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On Saturday 09 February 2008, Ingo Molnar wrote:
> ditto - hide this into cpu.h.
I did hide all the ifdefs into cpu.h as you suggested. See the new patch below.
>
> > static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
> > {
> > +#ifdef CONFIG_CPU_SUP_AMD
> > if (force_mwait)
> > return 1;
> > +#endif
>
> same - use cpu.h to define force_mwait to 0 if !CPU_SUP_AMD.
I didn't manage to, as force_mwait is also assigned in the same code.
I worked around the problem by declaring force_mwait elsewhere
(see my explanations in the patch comment)
---
[PATCH] x86 (Linux Tiny): configure out support for some processors
This patch against x86/mm tries to revive an original patch
from Matt Mackall which didn't get merged at that time. It makes
it possible to disable support code for some processors. This can
be useful to support only the exact processor type used
in a given system.
This patch allows to save up to 12K of text and data.
This time, I tried to use as few ifdefs as possible,
and move them away to include files.
Note that I had to modify include/asm-x86/bugs.h to declare
ppro_with_ram_bug() as an inline function. I hope there's
no harm.
Also note that for the sake of convenience and consistency
between 32 and 64 bit, I move the declaration of force_mwait
from kernel/cpu/amd.c to kernel/setup_32.c
(force_mwait is already defined in kernel/setup_64.c).
Thanks for your reviews! Michael.
Signed-off-by: Michael Opdenacker <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.cpu| 56 +
arch/x86/kernel/cpu/Makefile| 28 +-
arch/x86/kernel/cpu/amd.c |6 +-
arch/x86/kernel/cpu/centaur.c |2 +-
arch/x86/kernel/cpu/cpu.h | 124 +++
arch/x86/kernel/cpu/cyrix.c |4 +-
arch/x86/kernel/cpu/intel.c |6 +-
arch/x86/kernel/cpu/nexgen.c|2 +-
arch/x86/kernel/cpu/transmeta.c |2 +-
arch/x86/kernel/cpu/umc.c |2 +-
arch/x86/kernel/setup_32.c |2 +
arch/x86/mm/init_32.c |2 +
include/asm-x86/bugs.h |2 +-
13 files changed, 199 insertions(+), 39 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index e09a6b7..4fcd0fb 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -396,3 +396,59 @@ config X86_MINIMUM_CPU_FAMILY
config X86_DEBUGCTLMSR
def_bool y
depends on !(M586MMX || M586TSC || M586 || M486 || M386)
+
+menuconfig PROCESSOR_SELECT
+ depends on EMBEDDED && X86_32
+ bool "Supported processor vendors"
+ default n
+ help
+ This lets you choose what x86 vendor support code your kernel
+ will include.
+
+config CPU_SUP_INTEL
+ bool "Support Intel processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for Intel processors
+
+config CPU_SUP_CYRIX
+ bool "Support Cyrix processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for Cyrix processors
+
+config CPU_SUP_NSC
+ bool "Support NSC processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for NSC processors
+
+config CPU_SUP_AMD
+ bool "Support AMD processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for AMD processors
+
+config CPU_SUP_CENTAUR
+ bool "Support Centaur processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for Centaur processors
+
+config CPU_SUP_TRANSMETA
+ bool "Support Transmeta processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for Transmeta processors
+
+config CPU_SUP_NEXGEN
+ bool "Support NexGen processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for NexGen processors
+
+config CPU_SUP_UMC
+ bool "Support UMC processors" if PROCESSOR_SELECT
+ default y
+ help
+ This enables extended support for UMC processors
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a0c4d7c..a01cb67 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -2,20 +2,20 @@
# Makefile for x86-compatible CPU details and quirks
#
-obj-y := intel_cacheinfo.o addon_cpuid_features.o
-obj-y += feature_names.o
+obj-y := intel_cacheinfo.o addon_cpuid_features.o
+obj-y += feature_names.o
-obj-$(CONFIG_X86_32) += common.o proc.o bugs.o
-obj-$(CONFIG_X86_32) += amd.o
-obj-$(CONFIG_X86_32) += cyrix.o
-obj-$(CONFIG_X86_32) += centaur.o
-obj-$(CONFIG_X86_32) += transmeta.o
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
Michael Opdenacker wrote: Thanks for this report. Don't you think it's still useful to save up to 12 K of code that you don't use if you just have an Intel processor (for example)? For 12K it better be a very clean patch... which I don't consider this patch to be; it has way too many #ifdefs in the code. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
lør, 09 02 2008 kl. 10:29 +0100, skrev Michael Opdenacker: > On 02/09/2008 09:30 AM, Simon Holm Thøgersen wrote: > > The build of my currently running kernel for my laptop has > > $ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o > >textdata bss dec hex filename > >2809 316 03125 c35 amd.o > >2387 856 03243 cab cyrix.o > >1514 312 01826 722 centaur.o > >1279 312 01591 637 transmeta.o > >1783 316 02099 833 intel.o > > 126 312 0 438 1b6 nexgen.o > > 41 312 0 353 161 umc.o > >99392736 0 126753183 (TOTALS) > > > > That is without optimize for size compilation, with that set I get > > $ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o > >textdata bss dec hex filename > >2300 316 02616 a38 amd.o > >2132 820 02952 b88 cyrix.o > >1325 312 01637 665 centaur.o > >1151 312 01463 5b7 transmeta.o > >1575 316 01891 763 intel.o > > 107 312 0 419 1a3 nexgen.o > > 41 312 0 353 161 umc.o > >86312700 0 113312c43 (TOTALS) > > > > I don't think the code changes in the patch do much with respect to > > size. > > > Thanks for this report. Don't you think it's still useful to save up to > 12 K of code that you don't use if you just have an Intel processor (for > example)? The last remark was only about the code changes in arch/x86/kernel/cpu/common.c, arch/x86/kernel/process_32.c, arch/x86/kernel/process_64.c and arch/x86/mm/init_32.c, which my report didn't reflect upon since I never applied the patch. The ~12kB reduction no doubt has a good gain/pain ratio. Out of curiosity, how small a kernel are you targeting this work for? I guess your other post on 'make allnoconfig + CONFIG_EMBEDDED' has disabled more stuff than you would use in practice? Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On 02/09/2008 12:11 AM, Ingo Molnar wrote: > > would be nice to hide these #ifdefs into include files. (define > early_init_intel()/etc. as an empty inline in an include file) > Hi Ingo, Thank you very much for your quick review and your suggestions. I will try to post the corresponding update tonight. Cheers, Michael. -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On 02/09/2008 09:30 AM, Simon Holm Thøgersen wrote: > The build of my currently running kernel for my laptop has > $ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o >text data bss dec hex filename >2809 316 03125 c35 amd.o >2387 856 03243 cab cyrix.o >1514 312 01826 722 centaur.o >1279 312 01591 637 transmeta.o >1783 316 02099 833 intel.o > 126 312 0 438 1b6 nexgen.o > 41 312 0 353 161 umc.o >9939 2736 0 126753183 (TOTALS) > > That is without optimize for size compilation, with that set I get > $ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o >text data bss dec hex filename >2300 316 02616 a38 amd.o >2132 820 02952 b88 cyrix.o >1325 312 01637 665 centaur.o >1151 312 01463 5b7 transmeta.o >1575 316 01891 763 intel.o > 107 312 0 419 1a3 nexgen.o > 41 312 0 353 161 umc.o >8631 2700 0 113312c43 (TOTALS) > > I don't think the code changes in the patch do much with respect to > size. > Thanks for this report. Don't you think it's still useful to save up to 12 K of code that you don't use if you just have an Intel processor (for example)? Cheers, Michael. -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On 02/09/2008 12:20 AM, Matt Mackall wrote: > Please include the output of size with all these options on and off. > Oops, here they are: Standard kernel (original config: make allnoconfig + CONFIG_EMBEDDED): > size vmlinux textdata bss dec hex filename 966473 139000 90112 1195585 123e41 vmlinux Size of vmlinux: 1386005 With the patch (using only CONFIG_CPU_SUP_INTEL): > size vmlinux textdata bss dec hex filename 957561 136536 90112 1184209 1211d1 vmlinux (-9812) (-2464) Size of vmlinux: 1373697 (-12308 bytes) -12K in the kernel size looks quite nice to me. Michael. -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
fre, 08 02 2008 kl. 17:20 -0600, skrev Matt Mackall: > On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote: > > This patch against x86/mm tries to revive an original patch > > from Matt Mackall which didn't get merged at that time. It makes > > it possible to disable support code for some processors. This can > > be useful to support only the exact processor type used > > in a given system. > > > > I may have made wrong assumptions with the code handling > > force_mwait. As force_mwait is only declared in > > arch/x86/kernel/cpu/amd.c, which is only compiled > > when CONFIG_X86_32 is set, I thought it was safe > > to make the code depend on CONFIG_CPU_SUP_AMD, > > but I could be wrong. > > > > Your comments are more than welcome! To make the code > > cleaner, I could use empty inline functions instead > > of ifdef's, as suggested in Documentation/SubmittingPatches. > > Please include the output of size with all these options on and off. The build of my currently running kernel for my laptop has $ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o textdata bss dec hex filename 2809 316 03125 c35 amd.o 2387 856 03243 cab cyrix.o 1514 312 01826 722 centaur.o 1279 312 01591 637 transmeta.o 1783 316 02099 833 intel.o 126 312 0 438 1b6 nexgen.o 41 312 0 353 161 umc.o 99392736 0 126753183 (TOTALS) That is without optimize for size compilation, with that set I get $ size -t amd.o cyrix.o centaur.o transmeta.o intel.o nexgen.o umc.o textdata bss dec hex filename 2300 316 02616 a38 amd.o 2132 820 02952 b88 cyrix.o 1325 312 01637 665 centaur.o 1151 312 01463 5b7 transmeta.o 1575 316 01891 763 intel.o 107 312 0 419 1a3 nexgen.o 41 312 0 353 161 umc.o 86312700 0 113312c43 (TOTALS) I don't think the code changes in the patch do much with respect to size. Simon Holm Thøgersen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On 2/8/08, Michael Opdenacker <[EMAIL PROTECTED]> wrote: > +config CPU_SUP_INTEL > + default y > + bool "Support Intel processors" if PROCESSOR_SELECT > + help > + This enables extended support for Intel processors > -obj-$(CONFIG_X86_32) += intel.o > +obj-$(CONFIG_CPU_SUP_INTEL)+= intel.o This config option should probably depend on X86_32. -- Taral <[EMAIL PROTECTED]> "Please let me know if there's any further trouble I can give you." -- Unknown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote:
> This patch against x86/mm tries to revive an original patch
> from Matt Mackall which didn't get merged at that time. It makes
> it possible to disable support code for some processors. This can
> be useful to support only the exact processor type used
> in a given system.
>
> I may have made wrong assumptions with the code handling
> force_mwait. As force_mwait is only declared in
> arch/x86/kernel/cpu/amd.c, which is only compiled
> when CONFIG_X86_32 is set, I thought it was safe
> to make the code depend on CONFIG_CPU_SUP_AMD,
> but I could be wrong.
>
> Your comments are more than welcome! To make the code
> cleaner, I could use empty inline functions instead
> of ifdef's, as suggested in Documentation/SubmittingPatches.
Please include the output of size with all these options on and off.
> diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
> index dabdbef..8f9a123 100644
> --- a/arch/x86/kernel/process_32.c
> +++ b/arch/x86/kernel/process_32.c
> @@ -287,8 +287,10 @@ static void mwait_idle(void)
>
> static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
> {
> +#ifdef CONFIG_CPU_SUP_AMD
> if (force_mwait)
> return 1;
> +#endif
Probably makes sense to move force_mwait (one word) here and eliminate
these ifdefs.
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index 347a8cd..812bfa0 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -211,12 +211,14 @@ static void __init kernel_physical_mapping_init(pgd_t
> *pgd_base)
> }
> }
>
> +#ifdef CONFIG_CPU_SUP_INTEL
> static inline int page_kills_ppro(unsigned long pagenr)
> {
> if (pagenr >= 0x7 && pagenr <= 0x7003F)
> return 1;
> return 0;
> }
> +#endif
> /*
> * devmem_is_allowed() checks to see if /dev/mem access to a certain address
> @@ -287,7 +289,11 @@ static void __meminit free_new_highpage(struct page
> *page)
>
> void __init add_one_highpage_init(struct page *page, int pfn, int bad_ppro)
> {
> - if (page_is_ram(pfn) && !(bad_ppro && page_kills_ppro(pfn))) {
> + if (page_is_ram(pfn)
> +#ifdef CONFIG_CPU_SUP_INTEL
> + && !(bad_ppro && page_kills_ppro(pfn))
> +#endif
Yuck. A better way to do this is move the bad_ppro check into
page_kills_ppro and then ifdef out -the body- of the inline.
> @@ -592,7 +598,11 @@ void __init mem_init(void)
> #ifdef CONFIG_FLATMEM
> BUG_ON(!mem_map);
> #endif
> +#ifdef CONFIG_CPU_SUP_INTEL
> bad_ppro = ppro_with_ram_bug();
> +#else
> + bad_ppro = 0;
> +#endif
Again, move the storage for this, let it get initialized to zero
automatically, and initialize it in the CPU-specific code (if ordering
allows).
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
looks good to me, but the patch needs a serious #ifdef removal pass:
* Michael Opdenacker <[EMAIL PROTECTED]> wrote:
> switch (c->x86_vendor) {
> +#ifdef CONFIG_CPU_SUP_AMD
> case X86_VENDOR_AMD:
> early_init_amd(c);
> break;
> +#endif
> +#ifdef CONFIG_CPU_SUP_INTEL
> case X86_VENDOR_INTEL:
> early_init_intel(c);
> break;
> +#endif
would be nice to hide these #ifdefs into include files. (define
early_init_intel()/etc. as an empty inline in an include file)
> +#ifdef CONFIG_CPU_SUP_INTEL
> intel_cpu_init();
> +#endif
> +#ifdef CONFIG_CPU_SUP_CYRIX
> cyrix_init_cpu();
> +#endif
> +#ifdef CONFIG_CPU_SUP_NSC
> nsc_init_cpu();
> +#endif
> +#ifdef CONFIG_CPU_SUP_AMD
> amd_init_cpu();
> +#endif
> +#ifdef CONFIG_CPU_SUP_CENTAUR
> centaur_init_cpu();
> +#endif
> +#ifdef CONFIG_CPU_SUP_TRANSMETA
> transmeta_init_cpu();
> +#endif
> +#ifdef CONFIG_CPU_SUP_NEXGEN
> nexgen_init_cpu();
> +#endif
> +#ifdef CONFIG_CPU_SUP_UMC
> umc_init_cpu();
> +#endif
ditto - hide this into cpu.h.
> static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
> {
> +#ifdef CONFIG_CPU_SUP_AMD
> if (force_mwait)
> return 1;
> +#endif
same - use cpu.h to define force_mwait to 0 if !CPU_SUP_AMD.
> +#ifdef CONFIG_CPU_SUP_INTEL
> static inline int page_kills_ppro(unsigned long pagenr)
> {
> if (pagenr >= 0x7 && pagenr <= 0x7003F)
> return 1;
> return 0;
> }
> +#endif
put the #ifdef _inside_ the inline, thus:
> - if (page_is_ram(pfn) && !(bad_ppro && page_kills_ppro(pfn))) {
> + if (page_is_ram(pfn)
> +#ifdef CONFIG_CPU_SUP_INTEL
> + && !(bad_ppro && page_kills_ppro(pfn))
> +#endif
you can avoid this #ifdef. [handle bad_ppro too]
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 (Linux Tiny): configure out support for some processors
Michael Opdenacker wrote: This patch against x86/mm tries to revive an original patch from Matt Mackall which didn't get merged at that time. It makes it possible to disable support code for some processors. This can be useful to support only the exact processor type used in a given system. How much is it actually worth? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86 (Linux Tiny): configure out support for some processors
This patch against x86/mm tries to revive an original patch
from Matt Mackall which didn't get merged at that time. It makes
it possible to disable support code for some processors. This can
be useful to support only the exact processor type used
in a given system.
I may have made wrong assumptions with the code handling
force_mwait. As force_mwait is only declared in
arch/x86/kernel/cpu/amd.c, which is only compiled
when CONFIG_X86_32 is set, I thought it was safe
to make the code depend on CONFIG_CPU_SUP_AMD,
but I could be wrong.
Your comments are more than welcome! To make the code
cleaner, I could use empty inline functions instead
of ifdef's, as suggested in Documentation/SubmittingPatches.
Thanks for your reviews! Michael.
Signed-off-by: Michael Opdenacker <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.cpu | 55 ++
arch/x86/kernel/cpu/Makefile | 28 ++--
arch/x86/kernel/cpu/common.c | 20 +++
arch/x86/kernel/process_32.c |7 -
arch/x86/kernel/process_64.c |7 -
arch/x86/mm/init_32.c| 12 -
6 files changed, 112 insertions(+), 17 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index e09a6b7..5d9c9fb 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -396,3 +396,58 @@ config X86_MINIMUM_CPU_FAMILY
config X86_DEBUGCTLMSR
def_bool y
depends on !(M586MMX || M586TSC || M586 || M486 || M386)
+
+menuconfig PROCESSOR_SELECT
+ default y
+ bool "Supported processor vendors" if EMBEDDED
+ help
+ This lets you choose what x86 vendor support code your kernel
+ will include.
+
+config CPU_SUP_INTEL
+ default y
+ bool "Support Intel processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for Intel processors
+
+config CPU_SUP_CYRIX
+ default y
+ bool "Support Cyrix processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for Cyrix processors
+
+config CPU_SUP_NSC
+ default y
+ bool "Support NSC processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for NSC processors
+
+config CPU_SUP_AMD
+ default y
+ bool "Support AMD processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for AMD processors
+
+config CPU_SUP_CENTAUR
+ default y
+ bool "Support Centaur processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for Centaur processors
+
+config CPU_SUP_TRANSMETA
+ default y
+ bool "Support Transmeta processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for Transmeta processors
+
+config CPU_SUP_NEXGEN
+ default y
+ bool "Support NexGen processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for NexGen processors
+
+config CPU_SUP_UMC
+ default y
+ bool "Support UMC processors" if PROCESSOR_SELECT
+ help
+ This enables extended support for UMC processors
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a0c4d7c..a01cb67 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -2,20 +2,20 @@
# Makefile for x86-compatible CPU details and quirks
#
-obj-y := intel_cacheinfo.o addon_cpuid_features.o
-obj-y += feature_names.o
+obj-y := intel_cacheinfo.o addon_cpuid_features.o
+obj-y += feature_names.o
-obj-$(CONFIG_X86_32) += common.o proc.o bugs.o
-obj-$(CONFIG_X86_32) += amd.o
-obj-$(CONFIG_X86_32) += cyrix.o
-obj-$(CONFIG_X86_32) += centaur.o
-obj-$(CONFIG_X86_32) += transmeta.o
-obj-$(CONFIG_X86_32) += intel.o
-obj-$(CONFIG_X86_32) += nexgen.o
-obj-$(CONFIG_X86_32) += umc.o
+obj-$(CONFIG_X86_32) += common.o proc.o bugs.o
+obj-$(CONFIG_CPU_SUP_AMD) += amd.o
+obj-$(CONFIG_CPU_SUP_CYRIX)+= cyrix.o
+obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
+obj-$(CONFIG_CPU_SUP_TRANSMETA)+= transmeta.o
+obj-$(CONFIG_CPU_SUP_INTEL)+= intel.o
+obj-$(CONFIG_CPU_SUP_NEXGEN) += nexgen.o
+obj-$(CONFIG_CPU_SUP_UMC) += umc.o
-obj-$(CONFIG_X86_MCE) += mcheck/
-obj-$(CONFIG_MTRR) += mtrr/
-obj-$(CONFIG_CPU_FREQ) += cpufreq/
+obj-$(CONFIG_X86_MCE) += mcheck/
+obj-$(CONFIG_MTRR) += mtrr/
+obj-$(CONFIG_CPU_FREQ) += cpufreq/
-obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
+obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f86a3c4..1ed756c 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -329,12 +329,16 @@ static void __init early_cpu_detect(void)
get_cpu_vendor(c, 1);
switch (c->x86_vendor) {
+#ifdef CONFIG_CPU_SUP_AMD
case X86_VENDOR_AMD:
early_init_amd(c);
