public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][RFC] Create a top-level "Space-critical features" menu.
Date: Tue, 8 May 2007 10:56:54 +0200	[thread overview]
Message-ID: <20070508085654.GG4226@stusta.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0705080356020.10881@localhost.localdomain>

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


  parent reply	other threads:[~2007-05-08  8:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070508085654.GG4226@stusta.de \
    --to=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpjday@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox