From: Florian Mickler <florian@mickler.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Airlie <airlied@gmail.com>, Tejun Heo <tj@kernel.org>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
david@lang.hm
Subject: Re: kms in defconfig
Date: Tue, 28 Apr 2009 23:43:00 +0200 [thread overview]
Message-ID: <20090428234300.4a49d22f@schatten> (raw)
In-Reply-To: <alpine.LFD.2.00.0904281043420.22156@localhost.localdomain>
On Tue, 28 Apr 2009 10:50:14 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Tue, 28 Apr 2009, david@lang.hm wrote:
> > I've seen people talk about creating such tools, but the responses
> > that I've seen have tended to discourage them.
>
> I suspect that they'd generally end up handling the easy cases, and
> seldom anything more. At which point they're not all that useful.
>
> Linus
perhaps there needs to be an infrastructure where each
kconfig-entry-causer can also provide userlevel code to help with that
entry?
i could imagine a kconfig knob to specify an optional
per-kconfig-userspace-helperscript which calculates a new "suggested
value" at configure time.
this "suggested value" is displayed next to the default value
or is then already incorporated in the default value.
each maintainer of each kconfig entry
a) decides if it is possible to supply such a script
b) if it would be useful
c) suplies and maintains his (focused on only one kconfig entry) script
c) if the script is 100% fool-proof he can say so in the description of
the kconfig-entry or just skip the user or notify the user of the
result.
d) maybe dosn't provide an userspace helper
this spreads the burden of the complex detection-code and hopefully
eases configuration for everyone where possible.
what do others think?
sincerely,
Florian
next prev parent reply other threads:[~2009-04-28 21:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 8:21 kms in defconfig Dave Airlie
2009-04-27 8:39 ` Ingo Molnar
2009-04-27 8:56 ` Dave Airlie
2009-04-28 1:45 ` Tejun Heo
2009-04-28 1:59 ` Linus Torvalds
2009-04-28 6:29 ` Ingo Molnar
2009-04-28 16:54 ` david
2009-04-28 17:13 ` Linus Torvalds
2009-04-28 17:22 ` Ingo Molnar
2009-04-28 17:36 ` Steven Rostedt
2009-04-28 19:18 ` Ingo Molnar
2009-04-28 21:23 ` Steven Rostedt
2009-04-28 17:23 ` david
2009-04-28 17:50 ` Linus Torvalds
2009-04-28 21:43 ` Florian Mickler [this message]
2009-04-28 21:50 ` david
2009-04-28 23:10 ` Florian Mickler
2009-04-28 23:29 ` david
2009-04-29 6:55 ` Giacomo Catenazzi
2009-04-29 5:36 ` Andrew Morton
2009-04-29 5:59 ` Dave Airlie
2009-04-27 15:40 ` Peter Zijlstra
2009-04-28 1:54 ` Dave Airlie
2009-04-28 7:32 ` Peter Zijlstra
2009-04-28 17:04 ` Jesse Barnes
2009-04-28 23:42 ` Dave Airlie
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=20090428234300.4a49d22f@schatten \
--to=florian@mickler.org \
--cc=airlied@gmail.com \
--cc=david@lang.hm \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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