Re: kms in defconfig

[Giacomo Catenazzi]

Florian Mickler wrote:
> On Tue, 28 Apr 2009 10:50:14 -0700 (PDT)
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
>>
>> On Tue, 28 Apr 2009, david@xxxxxxx 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?

Not feasible!  Look at the default values or at the help text of options:
you see a lot of old and obsolete text.
Take e.g.: CONFIG_SMP, the intel AGP/DRI, or in general: help texts describe
usually only the first hardwares supported.
I think such scripts could not do better: soon will be obsolete.

It is also not difficult to do a central script.
I regularly build a map from modules, mosts buses, etc to the kernel config
(see lkddb.list in http://cateee.net/sources/lkddb ). With explicit
coding policy and few patches in kernel it would be easier to generate, but...

the problem is in Kconfig: actual interface is ugly:
it is difficult to know how to add support for an hardware, or to
remove a driver (because of linear dependencies and need to fullfil
the dependencies before to enable/disable drivers), and dependencies are
often not obvious.
Take a default kernel from your distribution and try to remove most of
non-needed hardware, using existing interfaces (ok, the Linus' sed method
simplify the problem, but try to do manually with menuconfig.

After we replace the build system we could try to develop a right
"autoconfiguration", which is IMHO a trivial task.
But the new build system need to solve dependencies (like modern
package managers). Actual system checks only dependencies, but user
must know and set it before to configure a specific item.

But creating a new configuration system, with dependency solver, is very
complex: the kernel has an interesting third state: "m". So we should handle
3 cases: n/m/y, and some policies:
- prefer m / prefer y
- default values
- on usefull (e.g. filesystems) "non hardware": n / m / y
  (but not on virtualization, debug)
- ...

So the old problem: automation and complexity: the solver must do the right thing,
but probably there is no "right thing" for everybody (or for most people), so we
cannot automatize it.

ciao
	cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/