linux-kernel - Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)

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] [day] [month] [year] [list]

Message-ID: <4D001BB4.4040906@oracle.com>
Date:	Wed, 08 Dec 2010 15:58:44 -0800
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	David Woodhouse <dwmw2@...radead.org>,
	Corentin Chary <corentin.chary@...il.com>,
	sedat.dilek@...il.com, Matthew Garrett <mjg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	platform-driver-x86@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error:
 recursive dependency detected!)

On 12/08/10 15:49, Dmitry Torokhov wrote:
> On Wed, Dec 08, 2010 at 11:35:08PM +0000, David Woodhouse wrote:
>> On Wed, 2010-12-08 at 15:31 -0800, Dmitry Torokhov wrote:
>>> Even better tool would allow selecting the needed optios right there,
>>> without the need of moving away from teh current option.
>>
>> That's exactly what the Nemesis version of xconfig did, almost 15 years
>> ago.
>>
>>>  And yet better tool would not even ask user and enable them on its
>>> own. Hey, but we have it! It's called "select".
>>
>> The tools could do that with 'depends on' too. Why make a distinction?
> 
> To allow automatic/manual selection. Sometimes the only answer to
> "shoudl it be enabled" is "Yes". I.e. drivers that need polling need
> input-polldev support. There is no reason whatsoever to even ask user.
> 
> Same thing for platform drivers. "Don't you also want to enable option for
> your keyboard and mouse to work? Go do that, you won't regret." "Well,
> duh!"
> 
>>
>>> Seriously, select is dangerous. I wonder if a rule like "One can only
>>> select a symbol whose dependencies are all satisfied by the current
>>> symbol and/or its parents and the symbols they select or depend on"
>>> would not make select safe enough. 
>>
>> "One can only select a symbol which isn't otherwise presented to the
>> user as a choice".
> 
> Input-polldev _is_ presented as a choice in case user or distro want to
> use out of tree driver that depends on it. Does this mean we shoudl
> disallow selects on it? I don't think so.

To me it means that we have too many config options, but I'm sure that some
embedded people would disagree with that.

| GUI tools have means of presenting this, menuconfig and oldconfig have
| harder time...

Sure, I know that.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/