Re: kms in defconfig

[Florian Mickler <florian@mickler.org>]

[-- Attachment #1: Type: text/plain, Size: 3752 bytes --]

On Tue, 28 Apr 2009 14:50:08 -0700 (PDT)
david@lang.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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]