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 platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
