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

[Randy Dunlap]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/