From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: Linux Embedded Maillist <linux-embedded@vger.kernel.org>
Subject: Re: Renaming of CONFIG_EMBEDDED to CONFIG_EXPERT
Date: Sat, 1 Jan 2011 17:47:45 -0500 [thread overview]
Message-ID: <20110101224745.GE30150@windriver.com> (raw)
In-Reply-To: <20110101080125.GA4040@opentech.at>
[Re: Renaming of CONFIG_EMBEDDED to CONFIG_EXPERT] On 01/01/2011 (Sat 09:01) Nicholas Mc Guire wrote:
> On Sat, 01 Jan 2011, Paul Gortmaker wrote:
>
> > Given the high traffic on LKML, some folks probably haven't seen this
> > thread, which proposes to rename the CONFIG_EMBEDDED option to
> > CONFIG_EXPERT.
> >
> > https://patchwork.kernel.org/patch/438671/
> >
> what would be the advantage of such a change ? is there an intent to introduce
> an actual CONFIG_EMBEDDED dedicated to embedded systems ?
I at first had a similar reaction, but the more I thought about it, the
more it seemed to make sense to me.
>
> The argument in the above patch that it requires experts to modify these
> settings holds for a lot of items in the kernel config and if that is the
> prime motivatino to flag these then an additional tag "EXPERT" along with
> "NEW" and "EXPERIMENTAL" might make more sense (Aside from the help text
> generally stating the sane-state any way with the common note that if you
> don't knwo what you are doing say N...)
Well, to be honest, the current EMBEDDED option allows you to see
options that you can easily shoot yourself in the foot with. And if you
are going to put together an embedded device, you largely do need
someone who is more familiar with the options (or at least willing to
research them) then the average desktop user who is contemplating
building a kernel for the 1st time. The term "expert" may be a bit
overdramatic, but at least it lets you know that you've strayed outside
the safety fence of the default playground.
THe guy who plays around with default /proc/sys/vm values to tune for a
64GB server has to know what he's doing just as another person tuning
the same settings for a 64MB router appliance -- both have to be an
"expert". So having a Kconfig that exposes the boot up defaults for VM
tuning (I didn't check, possibly a hypothetical example) doesn't make
sense to be hidden under EMBEDDED, but it does make sense to be under
the superset category of EXPERT, I think.
>
> The main objection I would have is that it will break documentation (out of
> tree docs that is) with little to no utility for the kernel developers.
The utility value is that we don't introduce yet another Kconfig option
that has a grey area of overlap with existing options.
Paul.
>
> hofrat
prev parent reply other threads:[~2011-01-01 22:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-01 5:30 Renaming of CONFIG_EMBEDDED to CONFIG_EXPERT Paul Gortmaker
2011-01-01 8:01 ` Nicholas Mc Guire
2011-01-01 22:47 ` Paul Gortmaker [this message]
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=20110101224745.GE30150@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=der.herr@hofr.at \
--cc=linux-embedded@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).