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

[Thadeu Lima de Souza Cascardo]

On Wed, Dec 08, 2010 at 02:12:17PM -0800, Dmitry Torokhov wrote:
> On Wed, Dec 08, 2010 at 01:51:05PM -0800, Randy Dunlap wrote:
> > 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.
> 
> I am 50/50 here. On one hand selecting whole subsystems may not be the
> best option, on the other hand (depending on how Kconfig is organized)
> it might make sense. Consider you have an USB joystick. You are in
> input, in joystick sub-menu, which comes _before_ USB. If you happen to
> have USB disabled then you, with your scheme, will not see the entry for
> the joystick. You will have to go into USB menu, activate USB and then
> go back and scan menus that you already been to for any new options. And
> again, and again. Not very friendly and so right now USB input devices
> do depend on INPUT, select USB and depend on USB_ARCH_HAS_HCD (to make
> sure USB can be activated).
> 
> Also, in case of CMPC, the user wants to support _all_ features of
> his/her laptop which is kind of useless without input, right?

Thanks, Dmitry, for building the case for CMPC. Besides input devices,
classmate-laptop only supports a single rfkill device. Currently, using
the driver without rfkill support is possible. That's not the case when
the input subsystem is disabled. I would like the user to go the the
platform/x86 menu and say 'hey, classmate support'.

That would however, be an argument for using select for everything, or
making depends work just like some dependencies resolvers work in
package management systems, like apt. OTOH, that would imply in lots of
undesired questions when someone does not want to enable anything that
depends on USB (or any bus or subsystem) at all.

For the case of CMPC, the user has already entered the platform/x86
menu. The CMPC option will not be visible if INPUT has been disabled.
And select works just fine here, since INPUT does not depend on
anything. OTOH, INPUT can only be disabled if EMBEDDED is enabled. And
if the user has done that, user must know what user is doing. So, if the
rule of thumb is that major subsystems should not be selected, I'd be
willing to submit of ack a patch fixing that.

Regards,
Cascardo.

Attachment: signature.asc
Description: Digital signature