tighten ATA kconfig dependancies
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)
drivers/ide/Kconfig renamed from drivers/ide/Kconfig~ +10 -4
@@ -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.
Signature · 1 line
http://www.codemonkey.org.uk
Quoted 1 line · Dave Jones
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...
Quoted 9 lines · Arjan van de Ven
Quoted 1 line · Dave Jones
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
Quoted 5 lines · Sam Ravnborg
Quoted 4 lines · Arjan van de Ven
Quoted 1 line · Dave Jones
A lot of prehistoric junk shows up on x86-64 configs.
Quoted 7 lines
Quoted 5 lines
... 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.
Quoted 10 lines · Arjan van de Ven
Quoted 9 lines · Sam Ravnborg
Quoted 8 lines · Arjan van de Ven
Quoted 1 line · Dave Jones
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
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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
Signature · 4 lines
"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 SeedQuoted 9 lines
Quoted 3 lines
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.
Quoted 10 lines · Arjan van de Ven
Quoted 9 lines
Quoted 3 lines
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.
Quoted 7 lines
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
Signature · 4 lines
"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 SeedAlan Cox
NAKQuoted 1 line · Dave Jones
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