Messages in this thread | | | From | David Woodhouse <> | Subject | Re: CML2 design philosophy heads-up | Date | Sun, 20 May 2001 16:34:26 +0100 |
| |
esr@thyrsus.com said: > I don't understand this request. I have no concept of `advisory' > dependencies. What are you talking about? Is my documentation > horribly unclear?
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/
| |