Messages in this thread | | | Date | Wed, 15 Nov 2017 14:37:54 +0100 | From | Takashi Iwai <> | Subject | Re: [GIT PULL] sound updates for 4.15-rc1 |
| |
On Wed, 15 Nov 2017 14:33:05 +0100, Mark Brown wrote: > > On Wed, Nov 15, 2017 at 02:16:41PM +0100, Takashi Iwai wrote: > > Mark Brown wrote: > > > > I'd say either just all the individual machines like it was or all the > > > SoCs. If it's the SoCs it prevents people making really tiny configs, > > > though I'm not sure who cares. If it's the machines then you get a lot > > > of options but I don't know that this is a problem, it's not like end > > > users are routinely configuring their kernel. > > > It might sound contradicting to my previous statement, but the number > > of selections itself isn't a big problem. The problem is rather that > > multiple options have to be selected for reaching to the point to > > enable one feature on your machine. So, I agree that these two > > Right, just finding what you need to enable to enable a given option. > > > representations would be suitable, and the usual solution is the > > firmer, to expose *only* individual machine drivers as selectable. > > It's definitely the most conservative thing to do, unless someone has a > strong reason to do something else I'd probably go that way. > > > (Or, at most, we can have kconfig entries just filtering in addition.) > > Yes, that'd not be quite so bad but it's still adding to the set of > things you have to grind through to find the option you want.
Right, but these filters are usually with default=y, so at the first invocation, it can go easy. The filter config is useful basically for someone who feel annoyed by too many options appearing, then they can turn this off explicitly.
Takashi
| |