Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[viro@ZenIV.linux.org.uk]

On Tue, Sep 06, 2005 at 12:52:34PM +0200, Roman Zippel wrote:
> I'm not really a big fan of such dummy symbols, those whole point is to 
> only enable dependencies, but are otherwise unsused.
> The basic problem is similiar to selects, that one has to grep the whole 
> Kconfig to find out what modifies the dependencies of a symbol.
> 
> If we really want to describe dependencies like this, I'd prefer to extend 
> the Kconfig syntax for this:
> 
> config FOO
> 	allow BAR
> 
> config BAR
> 	option hidden
> 
> The hidden option would explicitly hide the symbol, unless otherwise 
> allowed.

I doubt that we really need that - there are, fortunately, very few drivers
that need either form.

Note that what happens here is very unusual:
	* driver is for hardware shared by quite a few (sub)architectures
	* it requires different (and irregular) glue for all of them
	* it doesn't exist for more and more new architectures and never
existed for many old ones
	* the same is true for subarchitectures of arm/mips/ppc - hell, even
for m68k, except that there we don't get new ones.
	* it's not tied to any bus

Keeping a list of targets that must be excluded is obviously losing variant -
there will be more and more of those.  Flipping to "it's allowed on <list>"
generates a big mess; yeah, you get a long expression that tells you where
is that sucker defined.  And it turns into a convoluted way to say "many
platforms have that, many do not, it's really up to platform, no general
rules here".  Which is exactly what
	depends on ARCH_MAY_HAVE_PC_FDC
is saying in far more readable way.

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...