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