Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[viro@ZenIV.linux.org.uk]

On Tue, Sep 06, 2005 at 05:05:33PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Tue, 6 Sep 2005 viro@ZenIV.linux.org.uk wrote:
> 
> > We could go for your "allow" form, but what else would need it?  USB gadget
> > stuff with its "must have at most one low-level driver, high-level drivers
> > should be allowed only if a low-level one is present"?  RTC mess is better
> > solved in other ways, PARPORT_PC is mostly solved by now, what's left?
> > VGA_CONSOLE?  I really don't see enough uses for such construct...
> 
> It would be mostly useful for arm/mips with their millions of 
> configurations. Adding or removing one of them would become easier if the 
> references to it aren't spread over the complete.
> Basically select is already used (and sometimes abused) this way.

One major problem with that: unless you accept bare allow and/or select
(not as part of config <something>), we _still_ get these noise symbols,
just to have some place where that "allow" clause could live.

IOW, you get something like

config I_DONT_WANT_TO_CALL_THAT_ARCH_HAS_SOMETHING
	bool
	default y
	allow BLK_DEV_FD

in the same places where I do

config ARCH_MIGHT_HAVE_PC_FDC
	default y

with the only difference being that in your variant symbol will be 100%
semantics-free - it's just a workaround for Kconfig syntax problem.

Are you up to such change?  If so, I'll just take current patch and do
pretty much a search-and-replace on it, turning unconditional instances
of these suckers (i.e. in absense of subarchitectures) into plain

# there's a glue for PC-like FDC
allow BLD_DEV_FD

If you insist on having dummy config around allow/select, I don't see any
real benefits in using "allow" form...