By 'dependency' I refer to the case where the value of one symbol is derived
entirely from, or the range of possible values is limited by, the value of
another symbol.
There are differing reasons for this, which should be treated entirely
separately.
On one hand you have dependencies which are present to make life easier for
Aunt Tillie, by refraining from confusing her with strange questions to
which the answer is _probably_ 'no'. Like the question of whether she has
an IDE controller on her MVME board.
One the other hand, you have the dependencies present in the existing CML1
configuration, which are _absolute_ dependencies - which specify for example
that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc.
These dependencies are there to prevent you from enabling combinations of
options which are utterly meaningless, and usually won't even compile.
The former type of dependency should^HMUST be optional. Those who know what
they're doing will want to turn them off. I see a lot of boards based on
some reference design or other but with a few tweaks and added or removed
devices - that's what the reference designs are there for; after all.
By making a distinction between the two types of dependency in the
configuration language, you can pander to Aunt Tillie without actually
getting on the tits of those who don't wish to be arbitrarily restricted
from enabling support for the device they _know_ is present because they
just soldered it to the blinkin' circuit board. :)
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/