x86 (Linux Tiny): configure out support for some processors

x86 (Linux Tiny): configure out support for some processors

[Ingo Brueckl]

Is there any reason why CONFIG_PROCESSOR_SELECT is limited to EMBEDDED only?

In my desktop pc is one specific cpu only, so I do not need support for the
other processors. Unfortunately, I have no chance to disable the other ones.

As it is already configurable, why not giving this option to everyone?

Re: x86 (Linux Tiny): configure out support for some processors

[Bryan Donlan]

On Thu, Jan 1, 2009 at 3:37 PM, Ingo Brueckl <ib@wupperonline.de> wrote:
> Is there any reason why CONFIG_PROCESSOR_SELECT is limited to EMBEDDED only?
>
> In my desktop pc is one specific cpu only, so I do not need support for the
> other processors. Unfortunately, I have no chance to disable the other ones.
>
> As it is already configurable, why not giving this option to everyone?

EMBEDDED is just a switch to enable configuration options related to
removing 'core' features of the kernel to save space. Think of it as a
safety to avoid accidentally turning off something important. Feel
free to switch on EMBEDDED if you want to use CONFIG_PROCESSOR_SELECT
- just enabling EMBEDDED doesn't do anything by itself.

Re: x86 (Linux Tiny): configure out support for some processors

[Jaswinder Singh Rajput]

On Fri, Jan 2, 2009 at 10:49 AM, Bryan Donlan <bdonlan@gmail.com> wrote:
> On Thu, Jan 1, 2009 at 3:37 PM, Ingo Brueckl <ib@wupperonline.de> wrote:
>> Is there any reason why CONFIG_PROCESSOR_SELECT is limited to EMBEDDED only?
>>
>> In my desktop pc is one specific cpu only, so I do not need support for the
>> other processors. Unfortunately, I have no chance to disable the other ones.
>>
>> As it is already configurable, why not giving this option to everyone?
>
> EMBEDDED is just a switch to enable configuration options related to
> removing 'core' features of the kernel to save space. Think of it as a
> safety to avoid accidentally turning off something important. Feel
> free to switch on EMBEDDED if you want to use CONFIG_PROCESSOR_SELECT
> - just enabling EMBEDDED doesn't do anything by itself.

I think EMBEDDED is a misnomer for using CONFIG_PROCESSOR_SELECT and
should be used for more specific to Embedded stuff like for Embedded
range of CPUs or Embedded Systems.

Thank you,
JSR.

Re: x86 (Linux Tiny): configure out support for some processors

[Ingo Molnar]

* Jaswinder Singh Rajput <jaswinderlinux@gmail.com> wrote:

> On Fri, Jan 2, 2009 at 10:49 AM, Bryan Donlan <bdonlan@gmail.com> wrote:
> > On Thu, Jan 1, 2009 at 3:37 PM, Ingo Brueckl <ib@wupperonline.de> wrote:
> >> Is there any reason why CONFIG_PROCESSOR_SELECT is limited to EMBEDDED only?
> >>
> >> In my desktop pc is one specific cpu only, so I do not need support for the
> >> other processors. Unfortunately, I have no chance to disable the other ones.
> >>
> >> As it is already configurable, why not giving this option to everyone?
> >
> > EMBEDDED is just a switch to enable configuration options related to 
> > removing 'core' features of the kernel to save space. Think of it as a 
> > safety to avoid accidentally turning off something important. Feel 
> > free to switch on EMBEDDED if you want to use CONFIG_PROCESSOR_SELECT 
> > - just enabling EMBEDDED doesn't do anything by itself.
> 
> I think EMBEDDED is a misnomer for using CONFIG_PROCESSOR_SELECT and 
> should be used for more specific to Embedded stuff like for Embedded 
> range of CPUs or Embedded Systems.

i think EMBEDDED is justified in this particular case, as enabling 
CONFIG_PROCESSOR_SELECT allows you to create truly CPU-incompatible 
kernels. Kernels that panic on bootup on contemporary CPUs that happen to 
have a different manufacturer.

The normal CPU selection options (like CONFIG_MCORE2) are more like 
performance and preference hints not hard constraints - those kernels will 
generally still boot fine on most other CPUs as well. (with a few 
common-sense exceptions like booting on truly ancient CPUs, i.e. booting 
an CONFIG_MCORE2 kernel on an i486DX CPU will not work)

	Ingo

Re: x86 (Linux Tiny): configure out support for some processors

[Jaswinder Singh Rajput]

On Fri, Jan 2, 2009 at 3:08 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Jaswinder Singh Rajput <jaswinderlinux@gmail.com> wrote:
>>
>> I think EMBEDDED is a misnomer for using CONFIG_PROCESSOR_SELECT and
>> should be used for more specific to Embedded stuff like for Embedded
>> range of CPUs or Embedded Systems.
>
> i think EMBEDDED is justified in this particular case, as enabling
> CONFIG_PROCESSOR_SELECT allows you to create truly CPU-incompatible
> kernels. Kernels that panic on bootup on contemporary CPUs that happen to
> have a different manufacturer.
>

EMBEDDED leads to following options :
Configure standard kernel features (for small systems)
[*]   Enable 16-bit UID system calls (NEW)
[*]   Sysctl syscall support (NEW)
[*]   Load all symbols for debugging/ksymoops (NEW)
[*]     Include all symbols in kallsyms
[*]       Strip machine generated symbols from kallsyms
[*]     Do an extra kallsyms pass
[*]   Support for hot-pluggable devices (NEW)
[*]   Enable support for printk (NEW)

and these are perfect options for Embedded.

But selection of the PROCESSOR based on EMBEDDED is not a good logic.

CONFIG_PROCESSOR_SELECT should be an independent and by default should
select all related CPUs but user can specify its own CPU if he wants.

If I know what is my CPU there is no point for supporting all related
CPUs in my kernel.

This needs to be fixed.

Thank you,

JSR.

Re: x86 (Linux Tiny): configure out support for some processors

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Fri, 02 Jan 2009 20:40:16 +0530, Jaswinder Singh Rajput said:

> If I know what is my CPU there is no point for supporting all related
> CPUs in my kernel.

EMBEDDED is for a large assortment of things, all of which are of the form:

General users won't want to change Y, but if I know I don't need Y, there is
no point in supporting Y in the kernel.

Y might be "this kernel doesn't need sysctl"
Y might be "support for hot-plug"
Y might be "printk"
Y might be "support generic CPUs"

See the pattern?

Yes, we probably could have come up with a better name than EMBEDDED for
that list of optionals.

CONFIG_TRAINED_TECHNICIANS_ONLY_NO_USER_SERVICABLE_PARTS_INSIDE maybe?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: x86 (Linux Tiny): configure out support for some processors

[Jaswinder Singh Rajput]

On Fri, Jan 2, 2009 at 9:09 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Fri, 02 Jan 2009 20:40:16 +0530, Jaswinder Singh Rajput said:
>
>> If I know what is my CPU there is no point for supporting all related
>> CPUs in my kernel.
>
> EMBEDDED is for a large assortment of things, all of which are of the form:
>
> General users won't want to change Y, but if I know I don't need Y, there is
> no point in supporting Y in the kernel.
>

On 64 bit AMD machine I was getting :
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls

By using the following patch I get rid of extra CPU support and also
reduces size of the kernel.

Let me know why should I choose EMBEDDED option ? I know I am not
using Embbeded machine and I do not need embbeded features on my
machine. If I am willing to go North why should I go South first ?

--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -411,7 +411,7 @@ config X86_DEBUGCTLMSR
        depends on !(MK6 || MWINCHIPC6 || MWINCHIP3D || MCYRIXIII ||
M586MMX || M586TSC || M586 || M486 || M386)

 menuconfig PROCESSOR_SELECT
-       bool "Supported processor vendors" if EMBEDDED
+       bool "Supported processor vendors"
        help
          This lets you choose what x86 vendor support code your kernel
          will include.

Re: x86 (Linux Tiny): configure out support for some processors

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

On Fri, 02 Jan 2009 21:43:03 +0530, Jaswinder Singh Rajput said:

> Let me know why should I choose EMBEDDED option ? I know I am not
> using Embbeded machine and I do not need embbeded features on my
> machine. If I am willing to go North why should I go South first ?

EMBEDDED is a bad name for the option.  It *started* as "only those
maniac who need to trim their kernel WAY down should select this", and
ended up as "stuff that 95% of users shouldn't change, but you can if you
know what you're doing".

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: x86 (Linux Tiny): configure out support for some processors

[Ingo Molnar]

* Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:

> On Fri, 02 Jan 2009 21:43:03 +0530, Jaswinder Singh Rajput said:
> 
> > Let me know why should I choose EMBEDDED option ? I know I am not 
> > using Embbeded machine and I do not need embbeded features on my 
> > machine. If I am willing to go North why should I go South first ?
> 
> EMBEDDED is a bad name for the option.  It *started* as "only those 
> maniac who need to trim their kernel WAY down should select this", and 
> ended up as "stuff that 95% of users shouldn't change, but you can if 
> you know what you're doing".

i think both activities fit the generic 'embedded/specialized kernel' term 
quite well, so i dont think there's a big naming problem. There's maybe a 
documentation problem - the help text could be improved some more to 
signal that certain specialized config options are only available under 
CONFIG_EMBEDDED.

	Ingo

Re: x86 (Linux Tiny): configure out support for some processors

[Ingo Molnar]

* Jaswinder Singh Rajput <jaswinderlinux@gmail.com> wrote:

> On Fri, Jan 2, 2009 at 9:09 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> > On Fri, 02 Jan 2009 20:40:16 +0530, Jaswinder Singh Rajput said:
> >
> >> If I know what is my CPU there is no point for supporting all related
> >> CPUs in my kernel.
> >
> > EMBEDDED is for a large assortment of things, all of which are of the form:
> >
> > General users won't want to change Y, but if I know I don't need Y, there is
> > no point in supporting Y in the kernel.
> >
> 
> On 64 bit AMD machine I was getting :
> [    0.000000] KERNEL supported cpus:
> [    0.000000]   Intel GenuineIntel
> [    0.000000]   AMD AuthenticAMD
> [    0.000000]   Centaur CentaurHauls
> 
> By using the following patch I get rid of extra CPU support and also 
> reduces size of the kernel.

So you want to save kernel size by making less generic kernels tailored to 
a single box [yours in this case] - basically embedding the kernel on it?

> Let me know why should I choose EMBEDDED option ? I know I am not using 
> Embbeded machine and I do not need embbeded features on my machine. 
> [...]

that is what CONFIG_EMBEDDED=y means in broad terms: "make the kernel more 
specific [more embedded] to a particular hw/sw combination".

	Ingo

Re: x86 (Linux Tiny): configure out support for some processors

[Jaswinder Singh Rajput]

On Fri, Jan 2, 2009 at 9:51 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> So you want to save kernel size by making less generic kernels tailored to

My intention is to remove unwanted or useless data from kernel.

> a single box [yours in this case] - basically embedding the kernel on it?
>

So you mean choosing x86 is also EMBEDDED ? because it will not gonna
run on ARM machine.

>
> that is what CONFIG_EMBEDDED=y means in broad terms: "make the kernel more
> specific [more embedded] to a particular hw/sw combination".
>

Choosing drivers is also Embedded ?

Thanks you,
JSR

Re: x86 (Linux Tiny): configure out support for some processors

[Ingo Molnar]

* Jaswinder Singh Rajput <jaswinderlinux@gmail.com> wrote:

> On Fri, Jan 2, 2009 at 9:51 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > So you want to save kernel size by making less generic kernels tailored to
> 
> My intention is to remove unwanted or useless data from kernel.

which is one of the intentions of CONFIG_EMBEDDED too.

> > a single box [yours in this case] - basically embedding the kernel on 
> > it?
> >
> 
> So you mean choosing x86 is also EMBEDDED ? because it will not gonna 
> run on ARM machine.
> 
> > that is what CONFIG_EMBEDDED=y means in broad terms: "make the kernel 
> > more specific [more embedded] to a particular hw/sw combination".
> 
> Choosing drivers is also Embedded ?

if you bring the argument to its logical extreme then yes. (And human 
history is rich with pointless wars fought over various arguments brought 
to their logical extreme.)

a more pragmatic approach is that EMBEDDED is the specialization stuff 
that can break a box easily without the average kernel tester noticing 
why. Average kernel testers know about drivers and know about the 
architecture they run on. They might not know what apps rely on 
CONFIG_FUTEX for example.

They will probably be aware of the basic CPU type they are using - but the 
whole option brings only marginal benefits (on the order of 10 kilobytes 
of RAM) and the failure scenario is ugly. I have run into it myself: i 
booted a bzImage i assumed would work on a box but it wouldnt due to this. 
It's a subjective category and no amount of talking will bring any 
solution here.

	Ingo

Replace CONFIG_EMBEDDED [Was: x86 (Linux Tiny): configure out support for some processor]

[Sam Ravnborg]

> It's a subjective category and no amount of talking will bring any 
> solution here.

It is brought up now and then partly because the use of the
term EMBEDDED that is so overloaded that it is not fun.

Someone should kill it and replace it with something saner.

CONFIG_EXPERT_TEXT_SIZE

For stuff that the expert can toy with which mainly
has text size impact and some documented performance/functionality impact.
The possibility to select a subset of CPU's may belong here.


CONFIG_EXPERT_DATA_SIZE

Likewise where what we save is more data than TEXT.
For example where we lower the size of a hash bucket etc.

CONFIG_EXPERT

For other stuff that no 'ordinary' user will need to change
but the expert may find it usefull.

Everything we hide under EMBEDDED today would fit in the
categories above.

	Sam

Re: Replace CONFIG_EMBEDDED [Was: x86 (Linux Tiny): configure out support for some processor]

[Bill Davidsen]

Sam Ravnborg wrote:
>> It's a subjective category and no amount of talking will bring any 
>> solution here.
> 
> It is brought up now and then partly because the use of the
> term EMBEDDED that is so overloaded that it is not fun.
> 
> Someone should kill it and replace it with something saner.
> 
> CONFIG_EXPERT_TEXT_SIZE
> 
> For stuff that the expert can toy with which mainly
> has text size impact and some documented performance/functionality impact.
> The possibility to select a subset of CPU's may belong here.
> 
> 
> CONFIG_EXPERT_DATA_SIZE
> 
> Likewise where what we save is more data than TEXT.
> For example where we lower the size of a hash bucket etc.
> 
> CONFIG_EXPERT
> 
> For other stuff that no 'ordinary' user will need to change
> but the expert may find it usefull.
> 
> Everything we hide under EMBEDDED today would fit in the
> categories above.
> 
> 
Don't forget "CONFIG_EXPERT_STACK_SIZE" for 4k x86 stacks.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: Replace CONFIG_EMBEDDED [Was: x86 (Linux Tiny): configure out support for some processor]

[Sam Ravnborg]

> >CONFIG_EXPERT
> >
> >For other stuff that no 'ordinary' user will need to change
> >but the expert may find it usefull.
> >
> >Everything we hide under EMBEDDED today would fit in the
> >categories above.
> >
> >
> Don't forget "CONFIG_EXPERT_STACK_SIZE" for 4k x86 stacks.
I am not sure I follow you.
But changing the default stack size is a good candidate to hide
between CONFIG_EXPERT.

	Sam

Re: x86 (Linux Tiny): configure out support for some processors

[david]

On Fri, 2 Jan 2009, Valdis.Kletnieks@vt.edu wrote:

> On Fri, 02 Jan 2009 20:40:16 +0530, Jaswinder Singh Rajput said:
>
>> If I know what is my CPU there is no point for supporting all related
>> CPUs in my kernel.
>
> EMBEDDED is for a large assortment of things, all of which are of the form:
>
> General users won't want to change Y, but if I know I don't need Y, there is
> no point in supporting Y in the kernel.
>
> Y might be "this kernel doesn't need sysctl"
> Y might be "support for hot-plug"
> Y might be "printk"
> Y might be "support generic CPUs"
>
> See the pattern?
>
> Yes, we probably could have come up with a better name than EMBEDDED for
> that list of optionals.
>
> CONFIG_TRAINED_TECHNICIANS_ONLY_NO_USER_SERVICABLE_PARTS_INSIDE maybe?

having things outside of the embedded menu depend on embedded makes it 
hard for people to figure out what they need to do to disable specific 
things.

namespaces are also required if ! embedded, but namespaces are not (yet at 
least) something that is commonly used.

if you follow the logic you are providing to it's logical conclusion you 
may as well put all kernel config options under "I really know what I'm 
doing" top level lockout

David Lang

Re: x86 (Linux Tiny): configure out support for some processors

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Fri, 02 Jan 2009 08:51:28 PST, david@lang.hm said:
> having things outside of the embedded menu depend on embedded makes it 
> hard for people to figure out what they need to do to disable specific 
> things.

Odd, I can do a 'make menuconfig', do a /EARLY_PRINTK, and see:

 Symbol: EARLY_PRINTK [=y]                                               x  
  x Prompt: Early printk                                                    x  
  x   Defined at arch/x86/Kconfig.debug:33                                  x  
  x   Depends on: EMBEDDED                                                  x  
  x   Location:                                                             x  
  x     -> Kernel hacking

> if you follow the logic you are providing to it's logical conclusion you 
> may as well put all kernel config options under "I really know what I'm 
> doing" top level lockout

Hey, I didn't make up that logic. ;)

A large percentage of the kernel config options are things that really *could*
be one way or the other for any given system.  Maybe you want ext4, maybe you
don't.  Maybe you need process accounting, maybe you don't.  So they don't go
under EMBEDDED.  But we can be 98% sure that they probably want PRINTK.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: x86 (Linux Tiny): configure out support for some processors

[david]

On Fri, 2 Jan 2009, Valdis.Kletnieks@vt.edu wrote:

> On Fri, 02 Jan 2009 08:51:28 PST, david@lang.hm said:
>> having things outside of the embedded menu depend on embedded makes it
>> hard for people to figure out what they need to do to disable specific
>> things.
>
> Odd, I can do a 'make menuconfig', do a /EARLY_PRINTK, and see:
>
> Symbol: EARLY_PRINTK [=y]                                               x
>  x Prompt: Early printk                                                    x
>  x   Defined at arch/x86/Kconfig.debug:33                                  x
>  x   Depends on: EMBEDDED                                                  x
>  x   Location:                                                             x
>  x     -> Kernel hacking
>
>> if you follow the logic you are providing to it's logical conclusion you
>> may as well put all kernel config options under "I really know what I'm
>> doing" top level lockout
>
> Hey, I didn't make up that logic. ;)
>
> A large percentage of the kernel config options are things that really *could*
> be one way or the other for any given system.  Maybe you want ext4, maybe you
> don't.  Maybe you need process accounting, maybe you don't.  So they don't go
> under EMBEDDED.  But we can be 98% sure that they probably want PRINTK.

is there an easy way to pull the list of what symbols depend on EMBEDDED?

David Lang