On Wed, May 23, 2012 at 2:32 AM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> The reason we're selecting things from the users is that multi-level
> selects have never seemed to be terribly robust, they've been a
> noticable source of breakage with this sort of randconfig stuff in the
> past which is painful and annoying, especially given the strange fixes
> that tend to come from randconfig reports.
Multi-level pure selects *should* work correctly. So you can select
stuff that then in turn selects other stuff - and that should all be
fine.
It's *dependencies* that do not work.
So if you "select" something that depends on something else, you need
to make sure that you select all those dependencies (and because
recursive selects work, you have to check the entire *chain* of
selects to see the dependencies).
This is one reason why "select" is generally much more friendly than
"depends on". In general, we should strive to
- only make "depends on" for really *major* subsystems (like the
whole architecture, or something like networking), or on "pure user
helper variables" like the "You do want to see network drivers from
vendor Xyz" kind things.
This way "depends on" doesn't get too complicated: either it's
really big deals ("this works only on ARM") or it's high-level pure UI
stuff ("I won't bother to ask about fifteen different 3com cards,
because the user already said he isn't interested in 3com networking")
- use select for "the small details" - ie a driver should "select"
the helper stuff it needs and that people shouldn't need to even know
about (like random encryption engines etc).
but obviously there's a lot of gray areas in between, and then usually
it becomes an issue of "what are things that are sane to ask users".
But in general, a simple "select" is actually the *easiest* and most
straightforward thing, especially if the thing you are selecting
itself does not have any "depends on".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
