linux-kernel - Re: [GIT PULL] sound updates for 4.15-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Nov 2017 14:37:54 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Vinod Koul <vinod.koul@...el.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        alsa-devel@...a-project.org
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