Messages in this thread | | | Date | Sat, 23 May 2015 00:22:00 +0200 | From | "Luis R. Rodriguez" <> | Subject | Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses |
| |
On Fri, May 22, 2015 at 02:43:57PM -0700, josh@joshtriplett.org wrote: > On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote: > > So the question still stands -- are there any kconfig options which > > depend on EXPERT which enable folks to screw up run time (not just driver > > tweaks? > > I don't think it should be possible
OK, thanks!
> > So unless I'm missing a corner case, it would seem replacing "select FW_LOADER" > > with "depends on FW_LOADER" is a reasonable option so far. The subtleties lie > > then now in since EXPERT is used by most distributions, everyone is an expert, > > and: > > > > a) Do we want to be consistent about ensuring run time sanity of EXPERT? > > b) Should we split EXPERT into tweak / possible run time break options? > > "depends on FW_LOADER" and "select FW_LOADER" are equivalent from the > point of view of what configs they allow; they differ in how the > dependency is shown in UIs. > > However, from the sounds of things, you want to add a dependency to > FW_LOADER.
Nope the recursive case was that a new component which depends on FW_LOADER ended up selecting CRYPTO, and it turns out another driver which depends on FW_LOADER also depended on CRYPTO so that in turn creates a recursive dependency.
> So in that case, yeah, switch to depends rather than > rewriting Kconfig, unless you're feeling really ambitious.
OK so switching to "depends on" is the winning contender so far.
> > > > Note that not changing this means we *will* eventually run into the > > > > recursive dependency issue later, either with my FW API change patches > > > > or some other future feature. Likewise for any other kconfig option > > > > with similar semantics. > > By "recursive dependency issue", I'm guessing that someone wants to make > FW_LOADER depend on something else, which breaks because "select" > doesn't know how to recurse?
Kind of, the issue actually was a new component which depends on FW_LOADER and has crypto dependencies. Since the qat crypto driver selects FW_LOADER but also has a set of crypto dependencies that creates a recursive dependency loop.
> Ideally, someone should teach Kconfig to handle recursive dependencies, > but in the meantime using "depends" makes sense.
Doesn't sound like anyone is that enthusiastic about that.
So... shall we just switch to "depends on" tree-wide then for FW_LOADER?
Luis
| |