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:16:41 +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 13:16:48 +0100,
Mark Brown wrote:
> 
> On Wed, Nov 15, 2017 at 12:58:40PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> > > On Wed, Nov 15, 2017 at 08:34:09AM +0100, Takashi Iwai wrote:
> 
> > > Though transitioning back would probably just create more misery.
> > > It's a real shame that ACPI doesn't have standards for the machine
> > > descriptions here like DT does, it'd cut down on the amount of stuff
> > > that needs configuring.
> 
> > True.  Although I don't think ACPI is the center of the mess in this
> > case, but rather too many kconfigs is it.
> 
> It's the source of all the individual board Kconfigs - we can't just
> have an equivalent of the of-graph card - and then the explosion of
> board configs then pushes to have more of the other options user
> selectable to let people make the list more manageable.  

OK, point taken.

> > We should begin with thinking of which entries (and layer) to be
> > selectable, and which not.
> 
> 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
representations would be suitable, and the usual solution is the
firmer, to expose *only* individual machine drivers as selectable.
(Or, at most, we can have kconfig entries just filtering in addition.)


Takashi