tighten ATA kconfig dependancies

tighten ATA kconfig dependancies

[Dave Jones]

A lot of prehistoric junk shows up on x86-64 configs.

cmd640
- no-one in their right mind would use this on x86-32, let alone x86-64.

rz1000
- doesn't exist in 64bit form.

compaq triflex
- ditto

CY82C693
- unsure, really alpha only?

CS5520/CS5530/CS5535/SC1200
- 32bit only.

NS87415
- claims to be sparc/parisc only.

Serverworks
- AFAIK, OSB4/CSB5/CSB6 never showed up in 64bit form.
  (Maybe there is a god)

Signed-off-by: Dave Jones <davej@redhat.com>

--- linux-2.6.17.noarch/drivers/ide/Kconfig~	2006-07-15 01:24:18.000000000 -0400
+++ linux-2.6.17.noarch/drivers/ide/Kconfig	2006-07-15 01:29:47.000000000 -0400
@@ -282,7 +282,7 @@ config IDE_GENERIC
 
 config BLK_DEV_CMD640
 	bool "CMD640 chipset bugfix/support"
-	depends on X86
+	depends on X86_32
 	---help---
 	  The CMD-Technologies CMD640 IDE chip is used on many common 486 and
 	  Pentium motherboards, usually in combination with a "Neptune" or
@@ -377,7 +377,7 @@ config BLK_DEV_OPTI621
 
 config BLK_DEV_RZ1000
 	tristate "RZ1000 chipset bugfix/support"
-	depends on PCI && BLK_DEV_IDEPCI && X86
+	depends on PCI && BLK_DEV_IDEPCI && X86_32
 	help
 	  The PC-Technologies RZ1000 IDE chip is used on many common 486 and
 	  Pentium motherboards, usually along with the "Neptune" chipset.
@@ -508,12 +508,14 @@ config BLK_DEV_CMD64X
 
 config BLK_DEV_TRIFLEX
 	tristate "Compaq Triflex IDE support"
+	depends on X86_32
 	help
 	  Say Y here if you have a Compaq Triflex IDE controller, such
 	  as those commonly found on Compaq Pentium-Pro systems
 
 config BLK_DEV_CY82C693
 	tristate "CY82C693 chipset support"
+	depends on ALPHA
 	help
 	  This driver adds detection and support for the CY82C693 chipset
 	  used on Digital's PC-Alpha 164SX boards.
@@ -523,7 +525,7 @@ config BLK_DEV_CY82C693
 
 config BLK_DEV_CS5520
 	tristate "Cyrix CS5510/20 MediaGX chipset support (VERY EXPERIMENTAL)"
-	depends on EXPERIMENTAL
+	depends on X86_32 && EXPERIMENTAL
 	help
 	  Include support for PIO tuning and virtual DMA on the Cyrix MediaGX
 	  5510/5520 chipset. This will automatically be detected and
@@ -533,6 +535,7 @@ config BLK_DEV_CS5520
 
 config BLK_DEV_CS5530
 	tristate "Cyrix/National Semiconductor CS5530 MediaGX chipset support"
+	depends on X86_32
 	help
 	  Include support for UDMA on the Cyrix MediaGX 5530 chipset. This
 	  will automatically be detected and configured if found.
@@ -541,7 +544,7 @@ config BLK_DEV_CS5530
 
 config BLK_DEV_CS5535
 	tristate "AMD CS5535 chipset support"
-	depends on X86 && !X86_64
+	depends on X86_32
 	help
 	  Include support for UDMA on the NSC/AMD CS5535 companion chipset.
 	  This will automatically be detected and configured if found.
@@ -594,6 +597,7 @@ config BLK_DEV_HPT366
 
 config BLK_DEV_SC1200
 	tristate "National SCx200 chipset support"
+	depends on X86_32
 	help
 	  This driver adds support for the built in IDE on the National
 	  SCx200 series of embedded x86 "Geode" systems
@@ -623,6 +627,7 @@ config BLK_DEV_IT821X
 
 config BLK_DEV_NS87415
 	tristate "NS87415 chipset support"
+	depends on SPARC64 || PARISC
 	help
 	  This driver adds detection and support for the NS87415 chip
 	  (used mainly on SPARC64 and PA-RISC machines).
@@ -675,6 +680,7 @@ config BLK_DEV_PDC202XX_NEW
 
 config BLK_DEV_SVWKS
 	tristate "ServerWorks OSB4/CSB5/CSB6 chipsets support"
+	depends on X86_32
 	help
 	  This driver adds PIO/(U)DMA support for the ServerWorks OSB4/CSB5
 	  chipsets.
-- 
http://www.codemonkey.org.uk

Re: tighten ATA kconfig dependancies

[Arjan van de Ven]

On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> A lot of prehistoric junk shows up on x86-64 configs.


... but in general it helps compile testing if you're hacking stuff;
if your hacking IDE on x86-64 you now have to compile 32 bit as well to
see if you didn't break the compile for these as well

So please don't do this, just disable them in your config...

Re: tighten ATA kconfig dependancies

[Sam Ravnborg]

On Sat, Jul 15, 2006 at 07:49:08AM +0200, Arjan van de Ven wrote:
> On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> > A lot of prehistoric junk shows up on x86-64 configs.
> 
> 
> ... but in general it helps compile testing if you're hacking stuff;
> if your hacking IDE on x86-64 you now have to compile 32 bit as well to
> see if you didn't break the compile for these as well
> 
> So please don't do this, just disable them in your config...

An i686 cross compile chain seems to be the natural choice here?

	Sam

Re: tighten ATA kconfig dependancies

[Arjan van de Ven]

On Sat, 2006-07-15 at 08:38 +0200, Sam Ravnborg wrote:
> On Sat, Jul 15, 2006 at 07:49:08AM +0200, Arjan van de Ven wrote:
> > On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> > > A lot of prehistoric junk shows up on x86-64 configs.
> > 
> > 
> > ... but in general it helps compile testing if you're hacking stuff;
> > if your hacking IDE on x86-64 you now have to compile 32 bit as well to
> > see if you didn't break the compile for these as well
> > 
> > So please don't do this, just disable them in your config...
> 
> An i686 cross compile chain seems to be the natural choice here

the point is that it doesn't fall out naturally, and thus things get
needlessly missed.

Re: tighten ATA kconfig dependancies

[Adrian Bunk]

On Sat, Jul 15, 2006 at 08:45:56AM +0200, Arjan van de Ven wrote:
> On Sat, 2006-07-15 at 08:38 +0200, Sam Ravnborg wrote:
> > On Sat, Jul 15, 2006 at 07:49:08AM +0200, Arjan van de Ven wrote:
> > > On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> > > > A lot of prehistoric junk shows up on x86-64 configs.
> > > 
> > > 
> > > ... but in general it helps compile testing if you're hacking stuff;
> > > if your hacking IDE on x86-64 you now have to compile 32 bit as well to
> > > see if you didn't break the compile for these as well
> > > 
> > > So please don't do this, just disable them in your config...
> > 
> > An i686 cross compile chain seems to be the natural choice here
> 
> the point is that it doesn't fall out naturally, and thus things get
> needlessly missed.

It seems the main question is:
Is the kernel configuration mainly designed for users or for developers?

For users, showing drivers for hardware that is not present on their 
platform only causes confusion.

Only developers who want to do compile tests could benefit from 
compiling such drivers.

IMHO the kernel configuration is mainly designed for users.

We could do some kind of (X86_32 || DEVELOPER_COMPILE_TEST).

Or simply disable this driver on other platforms - these are only 
compile errors and amongst all possible problems in the kernel compile 
errors are amongst my least worries (obvious error, usually quickly 
fixed after the first bug report).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: tighten ATA kconfig dependancies

[Arjan van de Ven]

> > the point is that it doesn't fall out naturally, and thus things get
> > needlessly missed.
> 
> It seems the main question is:
> Is the kernel configuration mainly designed for users or for developers?
> 
> For users, showing drivers for hardware that is not present on their 
> platform only causes confusion.

well Aunt Tilly gets confused by all hardware that is not present on her
machine; she has no idea what a platform is. By that reasoning, we
should make kconfig hide all non-present hardware.

Also I think there is no difference in confusion between showing 10 or
15 IDE chipsets. Either the user knows what he has (and then it doesn't
matter) or those 10 are too much already.

Re: tighten ATA kconfig dependancies

[Bodo Eggert]

Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:

>> A lot of prehistoric junk shows up on x86-64 configs.
> 
> ... but in general it helps compile testing if you're hacking stuff;
> if your hacking IDE on x86-64 you now have to compile 32 bit as well to
> see if you didn't break the compile for these as well
> 
> So please don't do this, just disable them in your config...

If you want to compile test these drivers, just revert the patch or edit
the .config.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html

Re: tighten ATA kconfig dependancies

[Sam Ravnborg]

On Sat, Jul 15, 2006 at 08:38:01PM +0200, Bodo Eggert wrote:
> >> A lot of prehistoric junk shows up on x86-64 configs.
> > 
> > ... but in general it helps compile testing if you're hacking stuff;
> > if your hacking IDE on x86-64 you now have to compile 32 bit as well to
> > see if you didn't break the compile for these as well
> > 
> > So please don't do this, just disable them in your config...
> 
> If you want to compile test these drivers, just revert the patch or edit
> the .config.
Editing .config will not do the trick. kconfig will make sure the kernel
is build with a valid config so they will get turned off.

A cross compile toolchain is the only real soluion. Otherwise we would
soon end up with far to many drivers selectable for x84-64.

	Sam

Re: tighten ATA kconfig dependancies

[Arjan van de Ven]

> A cross compile toolchain is the only real soluion. Otherwise we would
> soon end up with far to many drivers selectable for x84-64.

if the *driver* is not platform specific, what is the problem with that?
Aunt Tilly again? The only difference between x86 and x86-64 is isa-bus
cards and things that were put on a motherboard but never on a PCI card.
That's maybe a dozen or two total for the entire kernel, and a set that
is not growing.

Re: tighten ATA kconfig dependancies

[Sam Ravnborg]

On Sun, Jul 16, 2006 at 08:04:47AM +0200, Arjan van de Ven wrote:
> 
> > A cross compile toolchain is the only real soluion. Otherwise we would
> > soon end up with far to many drivers selectable for x84-64.
> 
> if the *driver* is not platform specific, what is the problem with that?
and
> The only difference between x86 and x86-64 is isa-bus
> cards and things that were put on a motherboard but never on a PCI card.
and
> That's maybe a dozen or two total for the entire kernel, and a set that
> is not growing.
By that definition there are still a lot of candidates out-side the IDE
world. The x86 versus x86-64 is irrelevant here. The point is that
kconfig is used to select only relevant options for any given
architecture and with the above definition we could simply boil it down
to "make only what cannot compile for an arch non-selectable".

We have a nice kconfig system that is extensively used to secure we have
a valid kernel configuration all the time and we go long to secure this.
Should we now start to breake that apart to start to give drivers more
compile coverage just becasue that's a tad easier. That brakes the
fundamental of the kconfig in the first place namely to secure valid
configurations.

It is nto the IDE patch as such that is the topic here. It is the
general issue if kconfig at all shall allow one to select drivers that
is not suitable for your HW. Tomorrow it will be a bunch of ARM
drivers..

	Sam

Re: tighten ATA kconfig dependancies

[Adrian Bunk]

On Sat, Jul 15, 2006 at 12:56:43PM +0200, Arjan van de Ven wrote:
> 
> > > the point is that it doesn't fall out naturally, and thus things get
> > > needlessly missed.
> > 
> > It seems the main question is:
> > Is the kernel configuration mainly designed for users or for developers?
> > 
> > For users, showing drivers for hardware that is not present on their 
> > platform only causes confusion.
> 
> well Aunt Tilly gets confused by all hardware that is not present on her
> machine; she has no idea what a platform is. By that reasoning, we
> should make kconfig hide all non-present hardware.
> 
> Also I think there is no difference in confusion between showing 10 or
> 15 IDE chipsets. Either the user knows what he has (and then it doesn't
> matter) or those 10 are too much already.

It's not about Aunt Tilly, it's about an average systems administrator 
compiling his own kernel.

And there are already too many options visible, and the result are real 
world problems - I've seen it too often that someone didn't compile the 
support for his IDE chipset into the kernel. And this specific patch is 
only a small part of the general issue.

The situation was different if only developers and distributions would 
compile kernels, but that's not what's happening in the real world. 
Kernel developers are only a tiny minority amongst the people 
configuring and compiling their own kernel.

And if the "compile coverage" point was meant seriously, we'd also need 
some dummy #define's for getting all currently BROKEN_ON_SMP options 
compiling with CONFIG_SMP=y since in my experience they are getting
nearly zero compile coverage since it seems the "compile coverage" crowd 
only blindly runs allmdconfig/allyesconfig.

I'm often reporting and sometimes fixing compile errors, but that's OK.
Compile errors are really obvious errors (compared to e.g. runtime 
corruptions), and therefore not a real problem.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: tighten ATA kconfig dependancies

[Randy Dunlap]

> On Sat, Jul 15, 2006 at 08:45:56AM +0200, Arjan van de Ven wrote:
> > On Sat, 2006-07-15 at 08:38 +0200, Sam Ravnborg wrote:
> > > On Sat, Jul 15, 2006 at 07:49:08AM +0200, Arjan van de Ven wrote:
> > > > On Sat, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> > > > > A lot of prehistoric junk shows up on x86-64 configs.
> > > > 
> > > > 
> > > > ... but in general it helps compile testing if you're hacking stuff;
> > > > if your hacking IDE on x86-64 you now have to compile 32 bit as
well to
> > > > see if you didn't break the compile for these as well
> > > > 
> > > > So please don't do this, just disable them in your config...
> > > 
> > > An i686 cross compile chain seems to be the natural choice here
> > 
> > the point is that it doesn't fall out naturally, and thus things get
> > needlessly missed.
> 
> It seems the main question is:
> Is the kernel configuration mainly designed for users or for developers?
> 
> For users, showing drivers for hardware that is not present on their 
> platform only causes confusion.
> 
> Only developers who want to do compile tests could benefit from 
> compiling such drivers.
> 
> IMHO the kernel configuration is mainly designed for users.

or at least should be.

> We could do some kind of (X86_32 || DEVELOPER_COMPILE_TEST).

Let's not complicate it more.

> Or simply disable this driver on other platforms - these are only 
> compile errors and amongst all possible problems in the kernel compile 
> errors are amongst my least worries (obvious error, usually quickly 
> fixed after the first bug report).


---
~Randy

Re: tighten ATA kconfig dependancies

[Alan Cox]

On Sad, 2006-07-15 at 01:34 -0400, Dave Jones wrote:
> A lot of prehistoric junk shows up on x86-64 configs.

This is the old IDE layer, this isn't a bugfix or urgent so it isnt
appropriate for merging. It also makes testing and building more awkward
for maintainers.

This is the same policy we follow elsewhere in the kernel, filter stuff
that can't compile not general PCI stuff.

NAK