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
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,
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,
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
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
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
anations 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 usef
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
): 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
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
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.
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,
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
>
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
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
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.
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
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)
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
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
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.
34 matches
Mail list logo
