Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[Luis R. Rodriguez]

On Fri, May 22, 2015 at 02:43:57PM -0700, josh@xxxxxxxxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/