[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090428234300.4a49d22f@schatten>
Date: Tue, 28 Apr 2009 23:43:00 +0200
From: Florian Mickler <florian@...kler.org>
To: linux-kernel@...r.kernel.org
Cc: Dave Airlie <airlied@...il.com>, Tejun Heo <tj@...nel.org>,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>, david@...g.hm
Subject: Re: kms in defconfig
On Tue, 28 Apr 2009 10:50:14 -0700 (PDT)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>
> On Tue, 28 Apr 2009, david@...g.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists