public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH][RFC] Create a top-level "Space-critical features" menu.
@ 2007-05-08  8:06 Robert P. J. Day
  2007-05-08  8:21 ` Thomas Gleixner
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Robert P. J. Day @ 2007-05-08  8:06 UTC (permalink / raw)
  To: Linux Kernel Mailing List


  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
========================================================================

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:06 [PATCH][RFC] Create a top-level "Space-critical features" menu Robert P. J. Day
@ 2007-05-08  8:21 ` Thomas Gleixner
  2007-05-08  8:27   ` Robert P. J. Day
  2007-05-08  8:41   ` Robert P. J. Day
  2007-05-08  8:56 ` Adrian Bunk
  2007-05-08 20:10 ` Matt Mackall
  2 siblings, 2 replies; 13+ messages in thread
From: Thomas Gleixner @ 2007-05-08  8:21 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List

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)"




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:21 ` Thomas Gleixner
@ 2007-05-08  8:27   ` Robert P. J. Day
  2007-05-08  8:37     ` Thomas Gleixner
  2007-05-08  8:41   ` Robert P. J. Day
  1 sibling, 1 reply; 13+ messages in thread
From: Robert P. J. Day @ 2007-05-08  8:27 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linux Kernel Mailing List

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
========================================================================

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:27   ` Robert P. J. Day
@ 2007-05-08  8:37     ` Thomas Gleixner
  0 siblings, 0 replies; 13+ messages in thread
From: Thomas Gleixner @ 2007-05-08  8:37 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:21 ` Thomas Gleixner
  2007-05-08  8:27   ` Robert P. J. Day
@ 2007-05-08  8:41   ` Robert P. J. Day
  2007-05-08  9:21     ` Jan Engelhardt
  2007-05-08 20:22     ` Matt Mackall
  1 sibling, 2 replies; 13+ messages in thread
From: Robert P. J. Day @ 2007-05-08  8:41 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linux Kernel Mailing List

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
========================================================================

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:06 [PATCH][RFC] Create a top-level "Space-critical features" menu Robert P. J. Day
  2007-05-08  8:21 ` Thomas Gleixner
@ 2007-05-08  8:56 ` Adrian Bunk
  2007-05-08 16:14   ` Robert P. J. Day
  2007-05-08 20:10 ` Matt Mackall
  2 siblings, 1 reply; 13+ messages in thread
From: Adrian Bunk @ 2007-05-08  8:56 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:41   ` Robert P. J. Day
@ 2007-05-08  9:21     ` Jan Engelhardt
  2007-05-08 13:03       ` Stefan Richter
  2007-05-08 16:19       ` Robert P. J. Day
  2007-05-08 20:22     ` Matt Mackall
  1 sibling, 2 replies; 13+ messages in thread
From: Jan Engelhardt @ 2007-05-08  9:21 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Thomas Gleixner, Linux Kernel Mailing List


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
-- 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  9:21     ` Jan Engelhardt
@ 2007-05-08 13:03       ` Stefan Richter
  2007-05-08 16:19       ` Robert P. J. Day
  1 sibling, 0 replies; 13+ messages in thread
From: Stefan Richter @ 2007-05-08 13:03 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Robert P. J. Day, Thomas Gleixner, Linux Kernel Mailing List

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/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:56 ` Adrian Bunk
@ 2007-05-08 16:14   ` Robert P. J. Day
  0 siblings, 0 replies; 13+ messages in thread
From: Robert P. J. Day @ 2007-05-08 16:14 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Linux Kernel Mailing List

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
========================================================================

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  9:21     ` Jan Engelhardt
  2007-05-08 13:03       ` Stefan Richter
@ 2007-05-08 16:19       ` Robert P. J. Day
  1 sibling, 0 replies; 13+ messages in thread
From: Robert P. J. Day @ 2007-05-08 16:19 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Thomas Gleixner, Linux Kernel Mailing List

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
========================================================================

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:06 [PATCH][RFC] Create a top-level "Space-critical features" menu Robert P. J. Day
  2007-05-08  8:21 ` Thomas Gleixner
  2007-05-08  8:56 ` Adrian Bunk
@ 2007-05-08 20:10 ` Matt Mackall
  2007-05-08 20:34   ` Robert P. J. Day
  2 siblings, 1 reply; 13+ messages in thread
From: Matt Mackall @ 2007-05-08 20:10 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08  8:41   ` Robert P. J. Day
  2007-05-08  9:21     ` Jan Engelhardt
@ 2007-05-08 20:22     ` Matt Mackall
  1 sibling, 0 replies; 13+ messages in thread
From: Matt Mackall @ 2007-05-08 20:22 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Thomas Gleixner, Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
  2007-05-08 20:10 ` Matt Mackall
@ 2007-05-08 20:34   ` Robert P. J. Day
  0 siblings, 0 replies; 13+ messages in thread
From: Robert P. J. Day @ 2007-05-08 20:34 UTC (permalink / raw)
  To: Matt Mackall; +Cc: Linux Kernel Mailing List

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
========================================================================

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2007-05-08 20:35 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-08  8:06 [PATCH][RFC] Create a top-level "Space-critical features" menu Robert P. J. Day
2007-05-08  8:21 ` Thomas Gleixner
2007-05-08  8:27   ` Robert P. J. Day
2007-05-08  8:37     ` Thomas Gleixner
2007-05-08  8:41   ` Robert P. J. Day
2007-05-08  9:21     ` Jan Engelhardt
2007-05-08 13:03       ` Stefan Richter
2007-05-08 16:19       ` Robert P. J. Day
2007-05-08 20:22     ` Matt Mackall
2007-05-08  8:56 ` Adrian Bunk
2007-05-08 16:14   ` Robert P. J. Day
2007-05-08 20:10 ` Matt Mackall
2007-05-08 20:34   ` Robert P. J. Day

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox