[PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[viro]

Sanitized and fixed floppy dependencies: split the messy dependencies for
BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
are *not* going to have floppy.c compile, let alone work).

If you can come up with better name for that ("this architecture might
have working PC-compatible floppy disk controller"), you are more than
welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
below...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC13-git5-rio/arch/alpha/Kconfig RC13-git5-floppy/arch/alpha/Kconfig
--- RC13-git5-rio/arch/alpha/Kconfig	2005-08-28 23:09:39.000000000 -0400
+++ RC13-git5-floppy/arch/alpha/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -479,6 +479,9 @@
 	depends on ALPHA_GENERIC || ALPHA_JENSEN || ALPHA_ALCOR || ALPHA_MIKASA || ALPHA_SABLE || ALPHA_LYNX || ALPHA_NORITAKE || ALPHA_RAWHIDE
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	def_bool y
+
 config SMP
 	bool "Symmetric multi-processing support"
 	depends on ALPHA_SABLE || ALPHA_LYNX || ALPHA_RAWHIDE || ALPHA_DP264 || ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_GENERIC || ALPHA_SHARK || ALPHA_MARVEL
diff -urN RC13-git5-rio/arch/arm/Kconfig RC13-git5-floppy/arch/arm/Kconfig
--- RC13-git5-rio/arch/arm/Kconfig	2005-09-05 07:05:13.000000000 -0400
+++ RC13-git5-floppy/arch/arm/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -64,6 +64,9 @@
 config GENERIC_BUST_SPINLOCK
 	bool
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+
 config GENERIC_ISA_DMA
 	bool
 
@@ -150,6 +153,7 @@
 	select ARCH_ACORN
 	select FIQ
 	select TIMER_ACORN
+	select ARCH_MAY_HAVE_PC_FDC
 	help
 	  On the Acorn Risc-PC, Linux can support the internal IDE disk and
 	  CD-ROM interface, serial and parallel port, and the floppy drive.
diff -urN RC13-git5-rio/arch/arm/mach-footbridge/Kconfig RC13-git5-floppy/arch/arm/mach-footbridge/Kconfig
--- RC13-git5-rio/arch/arm/mach-footbridge/Kconfig	2005-06-17 15:48:29.000000000 -0400
+++ RC13-git5-floppy/arch/arm/mach-footbridge/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -87,6 +87,7 @@
 
 # EBSA285 board in either host or addin mode
 config ARCH_EBSA285
+	select ARCH_MAY_HAVE_PC_FDC
 	bool
 
 endif
diff -urN RC13-git5-rio/arch/arm26/Kconfig RC13-git5-floppy/arch/arm26/Kconfig
--- RC13-git5-rio/arch/arm26/Kconfig	2005-08-28 23:09:39.000000000 -0400
+++ RC13-git5-floppy/arch/arm26/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -55,6 +55,10 @@
 config GENERIC_ISA_DMA
 	bool
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff -urN RC13-git5-rio/arch/i386/Kconfig RC13-git5-floppy/arch/i386/Kconfig
--- RC13-git5-rio/arch/i386/Kconfig	2005-09-05 07:05:13.000000000 -0400
+++ RC13-git5-floppy/arch/i386/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -37,6 +37,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 source "init/Kconfig"
 
 menu "Processor type and features"
diff -urN RC13-git5-rio/arch/m68k/Kconfig RC13-git5-floppy/arch/m68k/Kconfig
--- RC13-git5-rio/arch/m68k/Kconfig	2005-09-05 16:40:38.000000000 -0400
+++ RC13-git5-floppy/arch/m68k/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -25,6 +25,11 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	depends on Q40 || (BROKEN && SUN3X)
+	default y
+
 mainmenu "Linux/68k Kernel Configuration"
 
 source "init/Kconfig"
diff -urN RC13-git5-rio/arch/mips/Kconfig RC13-git5-floppy/arch/mips/Kconfig
--- RC13-git5-rio/arch/mips/Kconfig	2005-09-05 07:05:13.000000000 -0400
+++ RC13-git5-floppy/arch/mips/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -4,6 +4,11 @@
 	# Horrible source of confusion.  Die, die, die ...
 	select EMBEDDED
 
+# shouldn't it be per-subarchitecture?
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 mainmenu "Linux/MIPS Kernel Configuration"
 
 source "init/Kconfig"
diff -urN RC13-git5-rio/arch/parisc/Kconfig RC13-git5-floppy/arch/parisc/Kconfig
--- RC13-git5-rio/arch/parisc/Kconfig	2005-08-28 23:09:40.000000000 -0400
+++ RC13-git5-floppy/arch/parisc/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -49,6 +49,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff -urN RC13-git5-rio/arch/ppc/Kconfig RC13-git5-floppy/arch/ppc/Kconfig
--- RC13-git5-rio/arch/ppc/Kconfig	2005-09-05 07:05:13.000000000 -0400
+++ RC13-git5-floppy/arch/ppc/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -47,6 +47,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 source "init/Kconfig"
 
 menu "Processor"
diff -urN RC13-git5-rio/arch/ppc64/Kconfig RC13-git5-floppy/arch/ppc64/Kconfig
--- RC13-git5-rio/arch/ppc64/Kconfig	2005-09-05 07:05:14.000000000 -0400
+++ RC13-git5-floppy/arch/ppc64/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -44,6 +44,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 # We optimistically allocate largepages from the VM, so make the limit
 # large enough (16MB). This badly named config option is actually
 # max order + 1
diff -urN RC13-git5-rio/arch/sh/Kconfig RC13-git5-floppy/arch/sh/Kconfig
--- RC13-git5-rio/arch/sh/Kconfig	2005-08-28 23:09:40.000000000 -0400
+++ RC13-git5-floppy/arch/sh/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -37,6 +37,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 source "init/Kconfig"
 
 menu "System type"
diff -urN RC13-git5-rio/arch/sparc/Kconfig RC13-git5-floppy/arch/sparc/Kconfig
--- RC13-git5-rio/arch/sparc/Kconfig	2005-08-28 23:09:40.000000000 -0400
+++ RC13-git5-floppy/arch/sparc/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -211,6 +211,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 config SUN_PM
 	bool
 	default y
diff -urN RC13-git5-rio/arch/sparc64/Kconfig RC13-git5-floppy/arch/sparc64/Kconfig
--- RC13-git5-rio/arch/sparc64/Kconfig	2005-09-05 07:05:14.000000000 -0400
+++ RC13-git5-floppy/arch/sparc64/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -26,6 +26,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 choice
 	prompt "Kernel page size"
 	default SPARC64_PAGE_SIZE_8KB
diff -urN RC13-git5-rio/arch/x86_64/Kconfig RC13-git5-floppy/arch/x86_64/Kconfig
--- RC13-git5-rio/arch/x86_64/Kconfig	2005-09-05 07:05:14.000000000 -0400
+++ RC13-git5-floppy/arch/x86_64/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -65,6 +65,10 @@
 	bool
 	default y
 
+config ARCH_MAY_HAVE_PC_FDC
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff -urN RC13-git5-rio/drivers/block/Kconfig RC13-git5-floppy/drivers/block/Kconfig
--- RC13-git5-rio/drivers/block/Kconfig	2005-09-05 07:05:14.000000000 -0400
+++ RC13-git5-floppy/drivers/block/Kconfig	2005-09-05 16:40:49.000000000 -0400
@@ -6,7 +6,7 @@
 
 config BLK_DEV_FD
 	tristate "Normal floppy disk support"
-	depends on (!ARCH_S390 && !M68K && !IA64 && !UML && !ARM) || Q40 || (SUN3X && BROKEN) || ARCH_RPC || ARCH_EBSA285
+	depends on ARCH_MAY_HAVE_PC_FDC
 	---help---
 	  If you want to use the floppy disk drive(s) of your PC under Linux,
 	  say Y. Information about this driver, especially important for IBM

Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[Roman Zippel]

Hi,

On Tue, 6 Sep 2005 viro@ZenIV.linux.org.uk wrote:

> Sanitized and fixed floppy dependencies: split the messy dependencies for
> BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
> BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
> to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
> BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
> are *not* going to have floppy.c compile, let alone work).

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.

bye, Roman

Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[viro]

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

Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[Geert Uytterhoeven]

On Tue, 6 Sep 2005 viro@ZenIV.linux.org.uk wrote:
> 	* the same is true for subarchitectures of arm/mips/ppc - hell, even
> for m68k, except that there we don't get new ones.

I wouldn't count on that... Coldfire with MMU, where are you? ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[Roman Zippel]

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.

bye, Roman

Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[viro]

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

Re: [PATCH] Kconfig fix (BLK_DEV_FD dependencies)

[Roman Zippel]

Hi,

On Tue, 6 Sep 2005 viro@ZenIV.linux.org.uk wrote:

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

It has to be in some context, otherwise Kconfig can't tell whether it 
belongs to the previous config or stands alone.
At the very last it needs something so it can be internally translated to

config y
	tristate
	allow BLD_DEV_FD

OTOH every arch already defines a "config <arch>", where things like this 
can be added.

bye, Roman