Re: CML2 design philosophy heads-up

[David Woodhouse <dwmw2@infradead.org>]

esr@thyrsus.com said:
>  I'll take that as a vote for (b), to handle even perverse
> configurations  even if it means adding a lot of complexity to the
> ruleset.

As long as the ruleset is sufficient to represent the desired parts of the 
original behaviour of CML1, that should be fine.

Which means that it must be possible to individually select drivers which
aren't standard for your board. The dependencies in CML1 are (supposed to
be) absolute - the 'advisory' dependencies you're adding are arguably a
useful feature, but please don't make it possible to confuse the two, and
please do make sure it's possible to disable the latter form.

I'm one of the people who Jes has heard saying both 'I don't care' and 
'NO!'. The latter on the occasions when it seems you're going to be 
reducing the usablility of the existing system.

I am happiest when my interaction with the config system consists only of 
'cvs {commit,update} .config' 'pico .config' and 'make oldconfig'. I don't 
configure kernels for new boards very often - but on the occasions I do, 
it's often embedded boards based on a reference design, with irrelevant 
hardware omitted and some new stuff added in.

Having the capability to fix up CVS conflicts in 'make oldconfig' would be 
a random feature creep that I _would_ approve of :)

--
dwmw2