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

Message-Id: <20101208135105.a8482d46.randy.dunlap@oracle.com>
Date:	Wed, 8 Dec 2010 13:51:05 -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 Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote:

> On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote:
> > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote:
> > > 
> > > I don't really see how it's a recursive dependency, but maybe it's
> > > time to clean this KConfig.
> > > What is our current policy about that ?
> > > 
> > > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > > and select obscure things so
> > > that the driver does not get lost if you don't enable the leds.
> > 
> > A better policy is: "NEVER USE SELECT".
> > 
> 
> No, this is BS. User selecting, for example, a button driver should not
> care that it is working in polling mode only and needs polled device
> library to work. As it was said before, drivers need to depend on major
> subsystems and select minors and library modules.

I dislike select, but reality is that modules do need to select/enable
library code and minor features sometimes.

OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT"
to enable an entire subsystem is wrong and bad IMO.


> The fact that our Kconfig can't really provide us with the functionality
> we desire (be it because the logic is fuzzy and hard to formalize or
> some other reason) shoud not force "NO SELECT" policy, we just need to
> be careful when using it.


---
~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/