Message-ID: <alpine.DEB.1.10.0904281622550.17268@asgard.lang.hm>
Date:	Tue, 28 Apr 2009 16:29:35 -0700 (PDT)
From:	david@...g.hm
To:	Florian Mickler <florian@...kler.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...il.com>, Tejun Heo <tj@...nel.org>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: kms in defconfig

On Wed, 29 Apr 2009, Florian Mickler wrote:

> On Tue, 28 Apr 2009 14:50:08 -0700 (PDT)
> david@...g.hm wrote:
>
>> On Tue, 28 Apr 2009, Florian Mickler wrote:
>>
>>> 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.
>>
>> what is the difference between the default value and this suggested
>> value?
>
> well... for example:
>
> ----snip----
> config MY_NEW_DRIVER
> bool "mynewDriver"
> default n
> helper obey
> help
>  this is my new shiny driver which speeds up the system by factor of
>  ten if the hardware is available. it the hardware is not available
>  this reduces performance by the factor of 5.
>  if unshure say 42.
> ----snap----
>
> and the helper line causes the Kconfig script to execute
> "some_path/userspacehelper.sh MY_NEW_DRIVER"
>
> with "obey", the return value would override the default value
>
> with "definitive_no", it would overide the default value with "no" if
> the script returned "no",
>
> with "definitive_yes", it would override the default value with "yes"
> if the script returned "yes"
>
> there could also be an msg displayed:
> "userspace config helper says: the machine seems to have the hardware
> but it has to be enabled in the bios!"
>
> maybe. maybe not.
>
> perhaps the "obey" "definitive_yes" "definitive_no" has to come from
> the helperscript too... dunno....
>
>
>>
>>> 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
>>
>> please no!!! we don't want to have to run 2000 different scripts to
>> get the settings.
>>
>> one script.
>>
>> David Lang
>
> hmm... alright, but that's not my main point here. the point is to
> have some infrastructure in the kconfig script for
> configure-time-hardware-detection.

_many_ people compile kernels on different hardware than they will be 
running it on.

keep the autodetect script seperate from the kernel compile/configure

in fact, if possible the autodetect script should not require the kernel 
source (to make it easier to do the autodetect on many different systems)

David Lang

> the rest is more an question of how to organize the work. however a
> modularized approach has more appeal in my eyes. but this was only
> me thinking out loud...
>
> there could be one script which facilitates the results of steve's
> allmod-cut-down script.
>
> i could also imagine having only one helperscript which knows it all.
> or there could be one which knows which script to call for what
> config-symbol.
>
> there could be the default-one, bundled with the kernel and
> third-party-scripts which may or may not fall back to the default one,
> but can override it.
>
> this would also enable some script to first generate some "hardware-id"
> and query the internet for known bad and known good config-facts for
> this platform and filter the in tree detection logic. (like when that
> machine has support for two equivalent services, but one is to be
> preferred on that platform because of a dumb biosbug or because of
> some social contract one has with the tasmanian devil)
>
> there are many options. it just needs to be done(tm)
>
> i'm gonna try to experiment a bit with smth like this, but maybe it
> turns out that the idea is not so good after all.  who knows...
>
>>
>>> 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