On Thu, 20 Oct 2016, Edward Cree wrote: > On 20/10/16 00:42, Nicolas Pitre wrote: > > diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt > > index 069fcb3eef..c96127f648 100644 > > --- a/Documentation/kbuild/kconfig-language.txt > > +++ b/Documentation/kbuild/kconfig-language.txt > > @@ -113,6 +113,33 @@ applicable everywhere (see syntax). > > That will limit the usefulness but on the other hand avoid > > the illegal configurations all over. > > > > +- weak reverse dependencies: "imply" <symbol> ["if" <expr>] > > + This is similar to "select" as it enforces a lower limit on another > > + symbol except that the "implied" config symbol's value may still be > > + set to n from a direct dependency or with a visible prompt. > > + Given the following example: > > + > > + config FOO > > + tristate > > + imply BAZ > > + > > + config BAZ > > + tristate > > + depends on BAr > > + > > + The following values are possible: > > + > > + FOO BAR BAR's default choice for BAZ > Should the third column not be "BAZ's default"? Indeed. Good catch. > > + --------------- --------------- --------------- -------------- > > + n y n N/m/y > > + m y m M/y/n > > + y y y Y/n > > + y n * N > Also, I don't think having any FOO=y should preclude BAZ=m. Suppose both > FOO and FOO2 imply BAZ, FOO=y and FOO2=m. Some people didn't like the fact that you could turn a driver from m to y and silently lose some features if they were provided by a subsystem that also used to be m, which arguably is not the same as being explicitly disabled. With "select" this is not a problem as the target symbol is also promoted to y in that case, so I wanted to preserve that property. > Then if BAZ-features are only > desired for driver FOO2, BAz=m makes sense. In that case it would make more sense to add a config option related to FOO asking if BAZ features are desired for that driver (there is already one occurrence of that with PTP). Or you could simply drop the "imply" statement from the FOO config entry. > There is also the case of drivers with the ability to detect at runtime > whether BAZ is present, rather than making the decision at build time, but > I'm not sure how common that is. Right now that's how PTP support is done. Drivers can optimize things at build time, but most of them simply cope with a NULL return from ptp_clock_register(). Hence the imply statement becomes a big configuration hint rather than some hard build dependency. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
