2007-05-08 08:07:16

by Robert P. J. Day

[permalink] [raw]
Subject: [PATCH][RFC] Create a top-level "Space-critical features" menu.


i've always hated that lower-level menu under "General setup":

Configure standard kernel features (for small systems) --->

which buries the choice of de-selecting features to save space one
level down without really explaining what it's all about. so i just
shifted all of that up to the top under what i think is a more
meaningful name.

this patch is also why i asked earlier why top-level menu entries
have no "help" text -- because, in this case, it would be useful for
someone looking at the config screen to see that choice and be able to
ask, "hey, i wonder what *that's* all about", and get help along the
lines of:

"these features are normally selected but, if you're strapped for
space, such as with embedded systems, you might consider turning some
of them off. if space isn't an issue, you might as well just leave
them as they are." (or something like that.)

---

diff --git a/init/Kconfig b/init/Kconfig
index ebe04f5..5d14096 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -346,23 +346,72 @@ config CC_OPTIMIZE_FOR_SIZE
config SYSCTL
bool

-menuconfig EMBEDDED
- bool "Configure standard kernel features (for small systems)"
+choice
+ prompt "Choose SLAB allocator"
+ default SLAB
+ help
+ This option allows to select a slab allocator.
+
+config SLAB
+ bool "SLAB"
+ help
+ The regular slab allocator that is established and known to work
+ well in all environments. It organizes chache hot objects in
+ per cpu and per node queues. SLAB is the default choice for
+ slab allocator.
+
+config SLUB
+ depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
+ bool "SLUB (Unqueued Allocator)"
help
- This option allows certain base kernel options and settings
- to be disabled or tweaked. This is for specialized
- environments which can tolerate a "non-standard" kernel.
- Only use this if you really know what you are doing.
+ SLUB is a slab allocator that minimizes cache line usage
+ instead of managing queues of cached objects (SLAB approach).
+ Per cpu caching is realized using slabs of objects instead
+ of queues of objects. SLUB can use memory efficiently
+ way and has enhanced diagnostics.
+
+config SLOB
+#
+# SLOB cannot support SMP because SLAB_DESTROY_BY_RCU does not work
+# properly.
+#
+ depends on EMBEDDED && !SMP && !SPARSEMEM
+ bool "SLOB (Simple Allocator)"
+ help
+ SLOB replaces the SLAB allocator with a drastically simpler
+ allocator. SLOB is more space efficient that SLAB but does not
+ scale well (single lock for all operations) and is more susceptible
+ to fragmentation. SLOB it is a great choice to reduce
+ memory usage and code size for embedded systems.
+
+endchoice
+
+endmenu # General setup
+
+config RT_MUTEXES
+ boolean
+ select PLIST
+
+config TINY_SHMEM
+ default !SHMEM
+ bool
+
+config BASE_SMALL
+ int
+ default 0 if BASE_FULL
+ default 1 if !BASE_FULL
+
+menu "Removable space-critical features"

config UID16
- bool "Enable 16-bit UID system calls" if EMBEDDED
+ bool "Enable 16-bit UID system calls"
depends on ARM || BFIN || CRIS || FRV || H8300 || X86_32 || M68K || (S390 && !64BIT) || SUPERH || SPARC32 || (SPARC64 && SPARC32_COMPAT) || UML || (X86_64 && IA32_EMULATION)
default y
help
This enables the legacy 16-bit UID syscall wrappers.

config SYSCTL_SYSCALL
- bool "Sysctl syscall support" if EMBEDDED
+ bool "Sysctl syscall support"
default y
select SYSCTL
---help---
@@ -378,7 +427,7 @@ config SYSCTL_SYSCALL
If unsure say Y here.

config KALLSYMS
- bool "Load all symbols for debugging/ksymoops" if EMBEDDED
+ bool "Load all symbols for debugging/ksymoops"
default y
help
Say Y here to let the kernel print out symbolic crash information and
@@ -409,7 +458,7 @@ config KALLSYMS_EXTRA_PASS


config HOTPLUG
- bool "Support for hot-pluggable devices" if EMBEDDED
+ bool "Support for hot-pluggable devices"
default y
help
This option is provided for the case where no hotplug or uevent
@@ -419,7 +468,7 @@ config HOTPLUG

config PRINTK
default y
- bool "Enable support for printk" if EMBEDDED
+ bool "Enable support for printk"
help
This option enables normal printk support. Removing it
eliminates most of the message strings from the kernel image
@@ -428,7 +477,7 @@ config PRINTK
strongly discouraged.

config BUG
- bool "BUG() support" if EMBEDDED
+ bool "BUG() support"
default y
help
Disabling this option eliminates support for BUG and WARN, reducing
@@ -439,20 +488,20 @@ config BUG

config ELF_CORE
default y
- bool "Enable ELF core dumps" if EMBEDDED
+ bool "Enable ELF core dumps"
help
Enable support for generating core dumps. Disabling saves about 4k.

config BASE_FULL
default y
- bool "Enable full-sized data structures for core" if EMBEDDED
+ bool "Enable full-sized data structures for core"
help
Disabling this option reduces the size of miscellaneous core
kernel data structures. This saves memory on small machines,
but may reduce performance.

config FUTEX
- bool "Enable futex support" if EMBEDDED
+ bool "Enable futex support"
default y
select RT_MUTEXES
help
@@ -461,14 +510,14 @@ config FUTEX
run glibc-based applications correctly.

config EPOLL
- bool "Enable eventpoll support" if EMBEDDED
+ bool "Enable eventpoll support"
default y
help
Disabling this option will cause the kernel to be built without
support for epoll family of system calls.

config SHMEM
- bool "Use full shmem filesystem" if EMBEDDED
+ bool "Use full shmem filesystem"
default y
depends on MMU
help
@@ -480,67 +529,14 @@ config SHMEM

config VM_EVENT_COUNTERS
default y
- bool "Enable VM event counters for /proc/vmstat" if EMBEDDED
+ bool "Enable VM event counters for /proc/vmstat"
help
VM event counters are needed for event counts to be shown.
This option allows the disabling of the VM event counters
on EMBEDDED systems. /proc/vmstat will only show page counts
if VM event counters are disabled.

-choice
- prompt "Choose SLAB allocator"
- default SLAB
- help
- This option allows to select a slab allocator.
-
-config SLAB
- bool "SLAB"
- help
- The regular slab allocator that is established and known to work
- well in all environments. It organizes chache hot objects in
- per cpu and per node queues. SLAB is the default choice for
- slab allocator.
-
-config SLUB
- depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
- bool "SLUB (Unqueued Allocator)"
- help
- SLUB is a slab allocator that minimizes cache line usage
- instead of managing queues of cached objects (SLAB approach).
- Per cpu caching is realized using slabs of objects instead
- of queues of objects. SLUB can use memory efficiently
- way and has enhanced diagnostics.
-
-config SLOB
-#
-# SLOB cannot support SMP because SLAB_DESTROY_BY_RCU does not work
-# properly.
-#
- depends on EMBEDDED && !SMP && !SPARSEMEM
- bool "SLOB (Simple Allocator)"
- help
- SLOB replaces the SLAB allocator with a drastically simpler
- allocator. SLOB is more space efficient that SLAB but does not
- scale well (single lock for all operations) and is more susceptible
- to fragmentation. SLOB it is a great choice to reduce
- memory usage and code size for embedded systems.
-
-endchoice
-
-endmenu # General setup
-
-config RT_MUTEXES
- boolean
- select PLIST
-
-config TINY_SHMEM
- default !SHMEM
- bool
-
-config BASE_SMALL
- int
- default 0 if BASE_FULL
- default 1 if !BASE_FULL
+endmenu

menu "Loadable module support"



--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================


2007-05-08 08:19:20

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 2007-05-08 at 04:06 -0400, Robert P. J. Day wrote:
> i've always hated that lower-level menu under "General setup":

Good reason to break everything which depends on CONFIG_EMBEDDED.

tglx

> -menuconfig EMBEDDED
> - bool "Configure standard kernel features (for small systems)"



2007-05-08 08:27:49

by Robert P. J. Day

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 8 May 2007, Thomas Gleixner wrote:

> On Tue, 2007-05-08 at 04:06 -0400, Robert P. J. Day wrote:
> > i've always hated that lower-level menu under "General setup":
>
> Good reason to break everything which depends on CONFIG_EMBEDDED.
>
> tglx
>
> > -menuconfig EMBEDDED
> > - bool "Configure standard kernel features (for small systems)"

i don't know what you're getting at here. are you saying this is a
bad idea because it will make a mess of the current usage of
CONFIG_EMBEDDED in the source tree?

$ grep -rw CONFIG_EMBEDDED *
... lots of irrelevant defconfig output deleted ...
drivers/pci/setup-res.c:#ifdef CONFIG_EMBEDDED
include/linux/ide.h:#if !defined(MAX_HWIFS) || defined(CONFIG_EMBEDDED)
$

i don't see a whole lot of impact here. more to the point, though,
the word "EMBEDDED" in this context is just wrong. people might have
*other* reasons to de-activate some of those features rather than just
for an embedded system.

granted, that's probably where it will *mostly* happen, but i prefer
the idea of labelling those selections for what they really are -- for
*saving* *space*, because that's exactly what they represent.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

2007-05-08 08:35:13

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 2007-05-08 at 04:27 -0400, Robert P. J. Day wrote:
> On Tue, 8 May 2007, Thomas Gleixner wrote:
>
> > On Tue, 2007-05-08 at 04:06 -0400, Robert P. J. Day wrote:
> > > i've always hated that lower-level menu under "General setup":
> >
> > Good reason to break everything which depends on CONFIG_EMBEDDED.
> >
> > tglx
> >
> > > -menuconfig EMBEDDED
> > > - bool "Configure standard kernel features (for small systems)"
>
> i don't know what you're getting at here. are you saying this is a
> bad idea because it will make a mess of the current usage of
> CONFIG_EMBEDDED in the source tree?
>
> $ grep -rw CONFIG_EMBEDDED *
> ... lots of irrelevant defconfig output deleted ...
> drivers/pci/setup-res.c:#ifdef CONFIG_EMBEDDED
> include/linux/ide.h:#if !defined(MAX_HWIFS) || defined(CONFIG_EMBEDDED)
> $

# find -iname Kconfig | xargs grep EMBEDDED

> i don't see a whole lot of impact here.

But there _IS_ impact. It does not matter whether it is a lot or not.

> more to the point, though,
> the word "EMBEDDED" in this context is just wrong. people might have
> *other* reasons to de-activate some of those features rather than just
> for an embedded system.
>
> granted, that's probably where it will *mostly* happen, but i prefer
> the idea of labelling those selections for what they really are -- for
> *saving* *space*, because that's exactly what they represent.

I prefer patches, which do not break things all over the place.

tglx


2007-05-08 08:42:34

by Robert P. J. Day

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 8 May 2007, Thomas Gleixner wrote:

> On Tue, 2007-05-08 at 04:06 -0400, Robert P. J. Day wrote:
> > i've always hated that lower-level menu under "General setup":
>
> Good reason to break everything which depends on CONFIG_EMBEDDED.
>
> tglx
>
> > -menuconfig EMBEDDED
> > - bool "Configure standard kernel features (for small systems)"

ah, now i see what you're getting at here:

$ grep EMBEDDED $(find . -name Kconfig\*)
./drivers/pcmcia/Kconfig: select CARDBUS if !EMBEDDED
./drivers/pcmcia/Kconfig: bool "Special initialization for O2Micro bridges" if EMBEDDED
./drivers/pcmcia/Kconfig: bool "Special initialization for Ricoh bridges" if EMBEDDED
./drivers/pcmcia/Kconfig: bool "Special initialization for TI and EnE bridges" if EMBEDDED
./drivers/pcmcia/Kconfig: bool "Auto-tune EnE bridges for CB cards" if EMBEDDED
./drivers/pcmcia/Kconfig: bool "Special initialization for Toshiba ToPIC bridges" if EMBEDDED
./drivers/ata/Kconfig: depends on EMBEDDED || ARCH_RPC
./drivers/acpi/Kconfig: bool "Power Management Timer Support" if EMBEDDED
./drivers/ide/Kconfig: depends on ALPHA || SUPERH || IA64 || EMBEDDED
... snip ...

in my opinion, the config option "EMBEDDED" is just plain silly. as
i mentioned earlier, there may be other reasons that people want to
de-activate normally selected features rather than just for strictly
embedded systems.

here's an example:

drivers/input/keyboard/Kconfig:
...
menuconfig INPUT_KEYBOARD
bool "Keyboards" if EMBEDDED || !X86
default y
...

so i should only be allowed to de-activate keyboard support if i
claim i'm working on an "embedded" system? that's absurd. maybe it's
a 64-CPU monster server that just happens to be running headless and
needs no keyboard. making that selection dependent on EMBEDDED is
just silly in that case.

anyway, must pack up and dash off for a few hours, but i'm hoping
you can see my point. i don't disagree that there should be a way to
de-select normally selected features. i just think the way it's being
done now is hideously misnamed.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

2007-05-08 08:56:59

by Adrian Bunk

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, May 08, 2007 at 04:06:30AM -0400, Robert P. J. Day wrote:
>
> i've always hated that lower-level menu under "General setup":
>
> Configure standard kernel features (for small systems) --->
>
> which buries the choice of de-selecting features to save space one
> level down without really explaining what it's all about. so i just
> shifted all of that up to the top under what i think is a more
> meaningful name.
>
> this patch is also why i asked earlier why top-level menu entries
> have no "help" text -- because, in this case, it would be useful for
> someone looking at the config screen to see that choice and be able to
> ask, "hey, i wonder what *that's* all about", and get help along the
> lines of:
>
> "these features are normally selected but, if you're strapped for
> space, such as with embedded systems, you might consider turning some
> of them off. if space isn't an issue, you might as well just leave
> them as they are." (or something like that.)
>...

I'm against it:

I don't have numbers, but I'd expect the vast majority of people
building kernels to be people with low kernel knowledge building for an
i386/x86_64 system.

OTOH, people developing embedded systems are most likely more familiar
with kernel internals.

Kernel size doesn't matter that much for average desktop or server
systems, and most things for possible space savings behind hidden behind
EMBEDDED are things where you _really_ have to know what you are doing
when playing with these options.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2007-05-08 09:22:46

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.


On May 8 2007 04:41, Robert P. J. Day wrote:
>
> in my opinion, the config option "EMBEDDED" is just plain silly. as
>i mentioned earlier, there may be other reasons that people want to
>de-activate normally selected features rather than just for strictly
>embedded systems.

Did not you want to make a patch row that expresses all your ideas, aka
CONFIG_EXPERT
CONFIG_ASKFORDETAILS (former CONFIG_EMBEDDED, e.g. "place in memory where
kernel is loaded")
CONFIG_OBSOLETE
CONFIG_DEPRECATED
etc.? :)



Jan
--

2007-05-08 13:04:12

by Stefan Richter

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

Jan Engelhardt wrote:
> On May 8 2007 04:41, Robert P. J. Day wrote:
>> in my opinion, the config option "EMBEDDED" is just plain silly. as
>>i mentioned earlier, there may be other reasons that people want to
>>de-activate normally selected features rather than just for strictly
>>embedded systems.
>
> Did not you want to make a patch row that expresses all your ideas, aka
> CONFIG_EXPERT
> CONFIG_ASKFORDETAILS (former CONFIG_EMBEDDED, e.g. "place in memory where
> kernel is loaded")

Some of this might be better left to GUIs or HOWTOs.

> CONFIG_OBSOLETE
> CONFIG_DEPRECATED
> etc.? :)
>
>
>
> Jan


--
Stefan Richter
-=====-=-=== -=-= -=---
http://arcgraph.de/sr/

2007-05-08 16:16:25

by Robert P. J. Day

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 8 May 2007, Adrian Bunk wrote:

> On Tue, May 08, 2007 at 04:06:30AM -0400, Robert P. J. Day wrote:
> >
> > i've always hated that lower-level menu under "General setup":
> >
> > Configure standard kernel features (for small systems) --->
> >
> > which buries the choice of de-selecting features to save space one
> > level down without really explaining what it's all about. so i just
> > shifted all of that up to the top under what i think is a more
> > meaningful name.
> >
> > this patch is also why i asked earlier why top-level menu entries
> > have no "help" text -- because, in this case, it would be useful for
> > someone looking at the config screen to see that choice and be able to
> > ask, "hey, i wonder what *that's* all about", and get help along the
> > lines of:
> >
> > "these features are normally selected but, if you're strapped for
> > space, such as with embedded systems, you might consider turning some
> > of them off. if space isn't an issue, you might as well just leave
> > them as they are." (or something like that.)
> >...
>
> I'm against it:
>
> I don't have numbers, but I'd expect the vast majority of people
> building kernels to be people with low kernel knowledge building for
> an i386/x86_64 system.

i agree. but a number of people have already suggested that that
lower-level menu

"Configure standard kernel features (for small systems)" --->

is not well-designed. and the very people you're talking about will
see that and not be quite sure what it represents. and they
*certainly* won't realize that *not* selecting it will have
consequences in other menus.

that particular menu is confusing for a number of reasons:

1) it's badly named
2) it has no help to explain it
3) even if you don't select it, it will still have some sub-menu
entries, which is non-intuitive
4) it's not at all clear that, if you don't select it, other possible
config entries all over the source tree won't be available.

> OTOH, people developing embedded systems are most likely more
> familiar with kernel internals.

i'm betting even embedded people might not understand what's going on
there. it's particularly confusing since, if you choose that option,
you will suddenly see a number of additional "small system" features
you can turn off, but there's no indication that options all over the
tree are suddenly becoming visible.

note: i have no problem with some kind of overall, top-level option
that does this sort of thing. i just don't think the current
technique is the right way. in fact, i think it's awful, and i'd love
to see it made more obvious.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

2007-05-08 16:19:43

by Robert P. J. Day

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 8 May 2007, Jan Engelhardt wrote:

>
> On May 8 2007 04:41, Robert P. J. Day wrote:
> >
> > in my opinion, the config option "EMBEDDED" is just plain silly. as
> >i mentioned earlier, there may be other reasons that people want to
> >de-activate normally selected features rather than just for strictly
> >embedded systems.
>
> Did not you want to make a patch row that expresses all your ideas, aka
> CONFIG_EXPERT
> CONFIG_ASKFORDETAILS (former CONFIG_EMBEDDED, e.g. "place in memory where
> kernel is loaded")
> CONFIG_OBSOLETE
> CONFIG_DEPRECATED
> etc.? :)

i hadn't actually considered *that* possibility, but the idea is sort
of what i had in mind -- a clear, top-level setting that, in one swell
foop, will change what's available throughout the tree. i think
that's the most intuitively clear way to do it.

rday

p.s. mostly, i just don't think labelling that selection with the
word "EMBEDDED" makes a lot of sense. who's to say that any given
feature should be de-selectable only on an embedded system?
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

2007-05-08 20:11:00

by Matt Mackall

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, May 08, 2007 at 04:06:30AM -0400, Robert P. J. Day wrote:
>
> i've always hated that lower-level menu under "General setup":
>
> Configure standard kernel features (for small systems) --->
>
> which buries the choice of de-selecting features to save space one
> level down without really explaining what it's all about. so i just
> shifted all of that up to the top under what i think is a more
> meaningful name.

WTF. It certainly does explain what it's all about (hint: hit '?') and
you've clearly failed to read it, even while creating the patch.

> this patch is also why i asked earlier why top-level menu entries
> have no "help" text -- because, in this case, it would be useful for
> someone looking at the config screen to see that choice and be able to
> ask, "hey, i wonder what *that's* all about", and get help along the
> lines of:
>
> "these features are normally selected but, if you're strapped for
> space, such as with embedded systems, you might consider turning some
> of them off. if space isn't an issue, you might as well just leave
> them as they are." (or something like that.)

NAK. Let's actually read that config option description:

menuconfig EMBEDDED
bool "Configure standard kernel features (for small systems)"
help
This option allows certain base kernel options and settings
to be disabled or tweaked. This is for specialized
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.

That means this option is for specialized environments which can
tolerate a non-standard kernel and people should only use it if they
really know what they're doing.

Think about what non-standard means. We absolutely don't want to hear
from anyone whose machine silently crashed only to discover they
accidentally had CONFIG_PRINTK off. None of the options in that menu
are of any interest to the average user and they shouldn't be using
them.

Feel free to suggest better help text if that isn't clear enough.

--
Mathematics is the supreme nostalgia of our time.

2007-05-08 20:22:32

by Matt Mackall

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, May 08, 2007 at 04:41:58AM -0400, Robert P. J. Day wrote:
> On Tue, 8 May 2007, Thomas Gleixner wrote:
>
> > On Tue, 2007-05-08 at 04:06 -0400, Robert P. J. Day wrote:
> > > i've always hated that lower-level menu under "General setup":
> >
> > Good reason to break everything which depends on CONFIG_EMBEDDED.
> >
> > tglx
> >
> > > -menuconfig EMBEDDED
> > > - bool "Configure standard kernel features (for small systems)"
>
> ah, now i see what you're getting at here:
>
> $ grep EMBEDDED $(find . -name Kconfig\*)
> ./drivers/pcmcia/Kconfig: select CARDBUS if !EMBEDDED
> ./drivers/pcmcia/Kconfig: bool "Special initialization for O2Micro bridges" if EMBEDDED
> ./drivers/pcmcia/Kconfig: bool "Special initialization for Ricoh bridges" if EMBEDDED
> ./drivers/pcmcia/Kconfig: bool "Special initialization for TI and EnE bridges" if EMBEDDED
> ./drivers/pcmcia/Kconfig: bool "Auto-tune EnE bridges for CB cards" if EMBEDDED
> ./drivers/pcmcia/Kconfig: bool "Special initialization for Toshiba ToPIC bridges" if EMBEDDED
> ./drivers/ata/Kconfig: depends on EMBEDDED || ARCH_RPC
> ./drivers/acpi/Kconfig: bool "Power Management Timer Support" if EMBEDDED
> ./drivers/ide/Kconfig: depends on ALPHA || SUPERH || IA64 || EMBEDDED
> ... snip ...
>
> in my opinion, the config option "EMBEDDED" is just plain silly. as
> i mentioned earlier, there may be other reasons that people want to
> de-activate normally selected features rather than just for strictly
> embedded systems.
>
> here's an example:
>
> drivers/input/keyboard/Kconfig:
> ...
> menuconfig INPUT_KEYBOARD
> bool "Keyboards" if EMBEDDED || !X86
> default y
> ...
>
> so i should only be allowed to de-activate keyboard support if i
> claim i'm working on an "embedded" system? that's absurd. maybe it's
> a 64-CPU monster server that just happens to be running headless and
> needs no keyboard. making that selection dependent on EMBEDDED is
> just silly in that case.

No, turning off keyboard on your 64-CPU monster server to save ~10k is
the thing that's absurd. More importantly, it's a support headache
because invariably someone will try to plug a keyboard in and complain
to us when it mysteriously doesn't work. If memory serves, Linus
himself did exactly that shortly after the current input layer was
merged.

--
Mathematics is the supreme nostalgia of our time.

2007-05-08 20:35:01

by Robert P. J. Day

[permalink] [raw]
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.

On Tue, 8 May 2007, Matt Mackall wrote:

> On Tue, May 08, 2007 at 04:06:30AM -0400, Robert P. J. Day wrote:
> >
> > i've always hated that lower-level menu under "General setup":
> >
> > Configure standard kernel features (for small systems) --->
> >
> > which buries the choice of de-selecting features to save space one
> > level down without really explaining what it's all about. so i just
> > shifted all of that up to the top under what i think is a more
> > meaningful name.
>
> WTF. It certainly does explain what it's all about (hint: hit '?') and
> you've clearly failed to read it, even while creating the patch.

you're right, i have no idea how i missed that. duh.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================