[EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
