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?
On Thu, Jan 1, 2009 at 3:37 PM, Ingo Brueckl <[email protected]> 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.
On Fri, Jan 2, 2009 at 10:49 AM, Bryan Donlan <[email protected]> wrote:
> On Thu, Jan 1, 2009 at 3:37 PM, Ingo Brueckl <[email protected]> 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.
* Jaswinder Singh Rajput <[email protected]> wrote:
> On Fri, Jan 2, 2009 at 10:49 AM, Bryan Donlan <[email protected]> wrote:
> > On Thu, Jan 1, 2009 at 3:37 PM, Ingo Brueckl <[email protected]> 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
On Fri, Jan 2, 2009 at 3:08 PM, Ingo Molnar <[email protected]> wrote:
>
> * Jaswinder Singh Rajput <[email protected]> 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.
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?
On Fri, 2 Jan 2009, [email protected] 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
On Fri, Jan 2, 2009 at 9:09 PM, <[email protected]> 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.
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".
* Jaswinder Singh Rajput <[email protected]> wrote:
> On Fri, Jan 2, 2009 at 9:09 PM, <[email protected]> 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
* [email protected] <[email protected]> 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
On Fri, 02 Jan 2009 08:51:28 PST, [email protected] 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.
On Fri, Jan 2, 2009 at 9:51 PM, Ingo Molnar <[email protected]> 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
* Jaswinder Singh Rajput <[email protected]> wrote:
> On Fri, Jan 2, 2009 at 9:51 PM, Ingo Molnar <[email protected]> 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
On Fri, 2 Jan 2009, [email protected] wrote:
> On Fri, 02 Jan 2009 08:51:28 PST, [email protected] 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
> 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
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
> >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