The patch below against 2.6.0-test2 does the following:
- let all drivers that don't compile depend on an undefined
CONFIG_BROKEN
- let all drivers that don't compile on SMP (due to cli/sti usage)
depend on a CONFIG_BROKEN_ON_SMP that is only defined if !CONFIG_SMP
Notes:
- I might have missed a few drivers, I found the drivers below by trying
to compile as many drivers as possible statically on i386
- I added in two drivers an #include <linux/interrupt.h> for the dummy
cli/sti #define's on !SMP to allow the compilation on UP
- as an example I converted the CONFIG_BLK_DEV_IDETAPE entry from a
dep_tristate comment to a full Kconfig entry with a dependency on
CONFIG_BROKEN (help text stolen from 2.4)
- I do prefer BROKEN, Alan prefers OBSOLETE
a s/BROKEN/OBSOLETE/g is acceptable for me
I'm not sure whether now or later in the 2.6.0-test phase is the right
time to apply this patch.
diffstat output:
drivers/atm/Kconfig | 4 ++--
drivers/cdrom/Kconfig | 8 ++++----
drivers/char/Kconfig | 31 ++++++++++++++++---------------
drivers/char/epca.c | 1 +
drivers/char/generic_serial.c | 1 +
drivers/i2c/Kconfig | 2 +-
drivers/ide/Kconfig | 26 +++++++++++++++++++++++++-
drivers/isdn/Kconfig | 2 +-
drivers/isdn/hardware/avm/Kconfig | 12 ++++++------
drivers/isdn/hisax/Kconfig | 2 ++
drivers/isdn/i4l/Kconfig | 1 +
drivers/media/video/Kconfig | 4 ++--
drivers/mtd/devices/Kconfig | 2 +-
drivers/net/Kconfig | 16 ++++++++--------
drivers/net/hamradio/Kconfig | 6 +++---
drivers/net/irda/Kconfig | 2 +-
drivers/net/tulip/Kconfig | 2 +-
drivers/net/wan/Kconfig | 8 ++++----
drivers/scsi/Kconfig | 20 ++++++++++----------
drivers/video/Kconfig | 6 +++---
fs/partitions/Kconfig | 1 +
init/Kconfig | 4 ++++
sound/oss/Kconfig | 2 +-
23 files changed, 99 insertions(+), 64 deletions(-)
cu
Adrian
--- linux-2.6.0-test2-full/drivers/net/tulip/Kconfig.old 2003-07-29 10:09:53.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/net/tulip/Kconfig 2003-07-29 10:10:34.000000000 +0200
@@ -131,7 +131,7 @@
config PCMCIA_XIRTULIP
tristate "Xircom Tulip-like CardBus support (old driver)"
- depends on NET_TULIP && CARDBUS
+ depends on NET_TULIP && CARDBUS && BROKEN_ON_SMP
---help---
This driver is for the Digital "Tulip" Ethernet CardBus adapters.
It should work with most DEC 21*4*-based chips/ethercards, as well
--- linux-2.6.0-test2-full/drivers/net/irda/Kconfig.old 2003-07-29 09:39:46.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/net/irda/Kconfig 2003-07-29 09:40:19.000000000 +0200
@@ -270,7 +270,7 @@
config TOSHIBA_OLD
tristate "Toshiba Type-O IR Port (old driver)"
- depends on IRDA
+ depends on IRDA && BROKEN_ON_SMP
help
Say Y here if you want to build support for the Toshiba Type-O IR
chipset. This chipset is used by the Toshiba Libretto 100CT, and
--- linux-2.6.0-test2-full/drivers/net/wan/Kconfig.old 2003-07-28 22:23:19.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/net/wan/Kconfig 2003-07-29 10:11:46.000000000 +0200
@@ -63,7 +63,7 @@
# Not updated to 2.6.
config COMX
tristate "MultiGate (COMX) synchronous serial boards support"
- depends on WAN && (ISA || PCI) && OBSOLETE
+ depends on WAN && (ISA || PCI) && BROKEN
---help---
Say Y if you want to use any board from the MultiGate (COMX) family.
These boards are synchronous serial adapters for the PC,
@@ -443,7 +443,7 @@
config SDLA
tristate "SDLA (Sangoma S502/S508) support"
- depends on DLCI && ISA
+ depends on DLCI && ISA && BROKEN_ON_SMP
help
Say Y here if you need a driver for the Sangoma S502A, S502E, and
S508 Frame Relay Access Devices. These are multi-protocol cards, but
@@ -476,7 +476,7 @@
config VENDOR_SANGOMA
tristate "Sangoma WANPIPE(tm) multiprotocol cards"
- depends on WAN_ROUTER_DRIVERS && WAN_ROUTER && (PCI || ISA)
+ depends on WAN_ROUTER_DRIVERS && WAN_ROUTER && (PCI || ISA) && BROKEN
---help---
WANPIPE from Sangoma Technologies Inc. (<http://www.sangoma.com/>)
is a family of intelligent multiprotocol WAN adapters with data
@@ -625,7 +625,7 @@
config X25_ASY
tristate "X.25 async driver (EXPERIMENTAL)"
- depends on WAN && LAPB && X25
+ depends on WAN && LAPB && X25 && BROKEN_ON_SMP
---help---
This is a driver for sending and receiving X.25 frames over regular
asynchronous serial lines such as telephone lines equipped with
--- linux-2.6.0-test2-full/drivers/net/hamradio/Kconfig.old 2003-07-29 09:27:25.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/net/hamradio/Kconfig 2003-07-29 09:39:25.000000000 +0200
@@ -1,6 +1,6 @@
config MKISS
tristate "Serial port KISS driver"
- depends on AX25
+ depends on AX25 && BROKEN_ON_SMP
---help---
KISS is a protocol used for the exchange of data between a computer
and a Terminal Node Controller (a small embedded system commonly
@@ -19,7 +19,7 @@
config 6PACK
tristate "Serial port 6PACK driver"
- depends on AX25
+ depends on AX25 && BROKEN_ON_SMP
---help---
6pack is a transmission protocol for the data exchange between your
PC and your TNC (the Terminal Node Controller acts as a kind of
@@ -49,7 +49,7 @@
config DMASCC
tristate "High-speed (DMA) SCC driver for AX.25"
- depends on ISA && AX25
+ depends on ISA && AX25 && BROKEN_ON_SMP
---help---
This is a driver for high-speed SCC boards, i.e. those supporting
DMA on one port. You usually use those boards to connect your
--- linux-2.6.0-test2-full/drivers/net/Kconfig.old 2003-07-28 22:23:19.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/net/Kconfig 2003-07-29 10:31:28.000000000 +0200
@@ -400,7 +400,7 @@
config MVME16x_NET
tristate "MVME16x Ethernet support"
- depends on NETDEVICES && MVME16x
+ depends on NETDEVICES && MVME16x && BROKEN_ON_SMP
help
This is the driver for the Ethernet interface on the Motorola
MVME162, 166, 167, 172 and 177 boards. Say Y here to include the
@@ -409,7 +409,7 @@
config BVME6000_NET
tristate "BVME6000 Ethernet support"
- depends on NETDEVICES && BVME6000
+ depends on NETDEVICES && BVME6000 && BROKEN_ON_SMP
help
This is the driver for the Ethernet interface on BVME4000 and
BVME6000 VME boards. Say Y here to include the driver for this chip
@@ -704,7 +704,7 @@
config ELMC_II
tristate "3c527 \"EtherLink/MC 32\" support (EXPERIMENTAL)"
- depends on NET_VENDOR_3COM && MCA && EXPERIMENTAL
+ depends on NET_VENDOR_3COM && MCA && EXPERIMENTAL && BROKEN_ON_SMP
help
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
@@ -882,7 +882,7 @@
config NI5010
tristate "NI5010 support (EXPERIMENTAL)"
- depends on NET_VENDOR_RACAL && ISA && EXPERIMENTAL
+ depends on NET_VENDOR_RACAL && ISA && EXPERIMENTAL && BROKEN_ON_SMP
---help---
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
@@ -1221,7 +1221,7 @@
config SKMC
tristate "SKnet MCA support"
- depends on NET_ETHERNET && MCA
+ depends on NET_ETHERNET && MCA && BROKEN
---help---
These are Micro Channel Ethernet adapters. You need to say Y to "MCA
support" in order to use this driver. Supported cards are the SKnet
@@ -1350,7 +1350,7 @@
config APRICOT
tristate "Apricot Xen-II on board Ethernet"
- depends on NET_PCI && ISA
+ depends on NET_PCI && ISA && BROKEN_ON_SMP
help
If you have a network (Ethernet) controller of this type, say Y and
read the Ethernet-HOWTO, available from
@@ -2144,7 +2144,7 @@
config DEFXX
tristate "Digital DEFEA and DEFPA adapter support"
- depends on FDDI && (PCI || EISA)
+ depends on FDDI && (PCI || EISA) && BROKEN
help
This is support for the DIGITAL series of EISA (DEFEA) and PCI
(DEFPA) controllers which can connect you to a local FDDI network.
@@ -2487,7 +2487,7 @@
config IPHASE5526
tristate "Interphase 5526 Tachyon chipset based adapter support"
- depends on NET_FC && SCSI && PCI
+ depends on NET_FC && SCSI && PCI && BROKEN
help
Say Y here if you have a Fibre Channel adaptor of this kind.
--- linux-2.6.0-test2-full/drivers/i2c/Kconfig.old 2003-07-29 00:58:38.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/i2c/Kconfig 2003-07-29 00:59:05.000000000 +0200
@@ -152,7 +152,7 @@
config I2C_ELEKTOR
tristate "Elektor ISA card"
- depends on I2C_ALGOPCF
+ depends on I2C_ALGOPCF && BROKEN_ON_SMP
help
This supports the PCF8584 ISA bus I2C adapter. Say Y if you own
such an adapter.
--- linux-2.6.0-test2-full/drivers/video/Kconfig.old 2003-07-28 22:23:20.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/video/Kconfig 2003-07-28 22:25:21.000000000 +0200
@@ -40,7 +40,7 @@
config FB_CIRRUS
tristate "Cirrus Logic support"
- depends on FB && (AMIGA || PCI)
+ depends on FB && (AMIGA || PCI) && BROKEN
---help---
This enables support for Cirrus Logic GD542x/543x based boards on
Amiga: SD64, Piccolo, Picasso II/II+, Picasso IV, or EGS Spectrum.
@@ -55,7 +55,7 @@
config FB_PM2
tristate "Permedia2 support"
- depends on FB && (AMIGA || PCI)
+ depends on FB && (AMIGA || PCI) && BROKEN
help
This is the frame buffer device driver for the Permedia2 AGP frame
buffer card from ASK, aka `Graphic Blaster Exxtreme'. There is a
@@ -802,7 +802,7 @@
config FB_PM3
tristate "Permedia3 support"
- depends on FB && PCI
+ depends on FB && PCI && BROKEN
help
This is the frame buffer device driver for the 3DLabs Permedia3
chipset, used in Formac ProFormance III, 3DLabs Oxygen VX1 &
--- linux-2.6.0-test2-full/drivers/isdn/hardware/avm/Kconfig.old 2003-07-29 01:57:44.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/isdn/hardware/avm/Kconfig 2003-07-29 01:58:59.000000000 +0200
@@ -12,13 +12,13 @@
config ISDN_DRV_AVMB1_B1ISA
tristate "AVM B1 ISA support"
- depends on CAPI_AVM && ISDN_CAPI && ISA
+ depends on CAPI_AVM && ISDN_CAPI && ISA && BROKEN_ON_SMP
help
Enable support for the ISA version of the AVM B1 card.
config ISDN_DRV_AVMB1_B1PCI
tristate "AVM B1 PCI support"
- depends on CAPI_AVM && ISDN_CAPI && PCI
+ depends on CAPI_AVM && ISDN_CAPI && PCI && BROKEN_ON_SMP
help
Enable support for the PCI version of the AVM B1 card.
@@ -30,14 +30,14 @@
config ISDN_DRV_AVMB1_T1ISA
tristate "AVM T1/T1-B ISA support"
- depends on CAPI_AVM && ISDN_CAPI && ISA
+ depends on CAPI_AVM && ISDN_CAPI && ISA && BROKEN_ON_SMP
help
Enable support for the AVM T1 T1B card.
Note: This is a PRI card and handle 30 B-channels.
config ISDN_DRV_AVMB1_B1PCMCIA
tristate "AVM B1/M1/M2 PCMCIA support"
- depends on CAPI_AVM && ISDN_CAPI
+ depends on CAPI_AVM && ISDN_CAPI && BROKEN_ON_SMP
help
Enable support for the PCMCIA version of the AVM B1 card.
@@ -50,14 +50,14 @@
config ISDN_DRV_AVMB1_T1PCI
tristate "AVM T1/T1-B PCI support"
- depends on CAPI_AVM && ISDN_CAPI && PCI
+ depends on CAPI_AVM && ISDN_CAPI && PCI && BROKEN_ON_SMP
help
Enable support for the AVM T1 T1B card.
Note: This is a PRI card and handle 30 B-channels.
config ISDN_DRV_AVMB1_C4
tristate "AVM C4/C2 support"
- depends on CAPI_AVM && ISDN_CAPI && PCI
+ depends on CAPI_AVM && ISDN_CAPI && PCI && BROKEN_ON_SMP
help
Enable support for the AVM C4/C2 PCI cards.
These cards handle 4/2 BRI ISDN lines (8/4 channels).
--- linux-2.6.0-test2-full/drivers/isdn/i4l/Kconfig.old 2003-07-28 22:23:20.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/isdn/i4l/Kconfig 2003-07-28 22:25:21.000000000 +0200
@@ -106,6 +106,7 @@
config ISDN_DIVERSION
tristate "Support isdn diversion services"
+ depends on BROKEN
help
This option allows you to use some supplementary diversion
services in conjunction with the HiSax driver on an EURO/DSS1
--- linux-2.6.0-test2-full/drivers/isdn/hisax/Kconfig.old 2003-07-28 22:23:20.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/isdn/hisax/Kconfig 2003-07-28 22:25:21.000000000 +0200
@@ -165,6 +165,7 @@
config HISAX_DIEHLDIVA
bool "Eicon.Diehl Diva cards"
+ depends on !ISAPNP || BROKEN
help
This enables HiSax support for the Eicon.Diehl Diva none PRO
versions passive ISDN cards.
@@ -207,6 +208,7 @@
config HISAX_SEDLBAUER
bool "Sedlbauer cards"
+ depends on !ISAPNP || BROKEN
help
This enables HiSax support for the Sedlbauer passive ISDN cards.
--- linux-2.6.0-test2-full/drivers/isdn/Kconfig.old 2003-07-29 01:50:25.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/isdn/Kconfig 2003-07-29 01:50:48.000000000 +0200
@@ -22,7 +22,7 @@
menu "Old ISDN4Linux"
- depends on NET && ISDN_BOOL
+ depends on NET && ISDN_BOOL && BROKEN_ON_SMP
config ISDN
tristate "Old ISDN4Linux (obsolete)"
--- linux-2.6.0-test2-full/drivers/media/video/Kconfig.old 2003-07-28 22:23:20.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/media/video/Kconfig 2003-07-28 22:25:21.000000000 +0200
@@ -161,7 +161,7 @@
config VIDEO_ZORAN
tristate "Zoran ZR36057/36060 Video For Linux"
- depends on VIDEO_DEV && PCI && I2C
+ depends on VIDEO_DEV && PCI && I2C && BROKEN
help
Say Y here to include support for video cards based on the Zoran
ZR36057/36060 encoder/decoder chip (including the Iomega Buz and the
@@ -190,7 +190,7 @@
config VIDEO_ZR36120
tristate "Zoran ZR36120/36125 Video For Linux"
- depends on VIDEO_DEV && PCI && I2C
+ depends on VIDEO_DEV && PCI && I2C && BROKEN
help
Support for ZR36120/ZR36125 based frame grabber/overlay boards.
This includes the Victor II, WaveWatcher, Video Wonder, Maxi-TV,
--- linux-2.6.0-test2-full/drivers/char/epca.c.old 2003-07-28 22:23:20.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/char/epca.c 2003-07-28 22:25:21.000000000 +0200
@@ -40,6 +40,7 @@
#include <linux/tty_flip.h>
#include <linux/slab.h>
#include <linux/ioport.h>
+#include <linux/interrupt.h>
#include <asm/uaccess.h>
#include <asm/io.h>
--- linux-2.6.0-test2-full/drivers/char/Kconfig.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/char/Kconfig 2003-07-29 00:50:26.000000000 +0200
@@ -78,7 +78,7 @@
config COMPUTONE
tristate "Computone IntelliPort Plus serial support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
---help---
This driver supports the entire family of Intelliport II/Plus
controllers with the exception of the MicroChannel controllers and
@@ -111,7 +111,7 @@
config CYCLADES
tristate "Cyclades async mux support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
---help---
This is a driver for a card that gives you many serial ports. You
would need something like this to connect more than two modems to
@@ -143,7 +143,7 @@
config DIGIEPCA
tristate "Digiboard Intelligent Async Support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
---help---
This is a driver for Digi International's Xx, Xeve, and Xem series
of cards which provide multiple serial ports. You would need
@@ -162,7 +162,7 @@
config DIGI
tristate "Digiboard PC/Xx Support"
- depends on SERIAL_NONSTANDARD && DIGIEPCA=n
+ depends on SERIAL_NONSTANDARD && DIGIEPCA=n && BROKEN
help
This is a driver for the Digiboard PC/Xe, PC/Xi, and PC/Xeve cards
that give you many serial ports. You would need something like this
@@ -175,7 +175,7 @@
config ESPSERIAL
tristate "Hayes ESP serial port support"
- depends on SERIAL_NONSTANDARD && ISA
+ depends on SERIAL_NONSTANDARD && ISA && BROKEN
help
This is a driver which supports Hayes ESP serial ports. Both single
port cards and multiport cards are supported. Make sure to read
@@ -188,7 +188,7 @@
config MOXA_INTELLIO
tristate "Moxa Intellio support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
help
Say Y here if you have a Moxa Intellio multiport serial card.
@@ -199,7 +199,7 @@
config MOXA_SMARTIO
tristate "Moxa SmartIO support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
help
Say Y here if you have a Moxa SmartIO multiport serial card.
@@ -260,7 +260,7 @@
config RISCOM8
tristate "SDL RISCom/8 card support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN
help
This is a driver for the SDL Communications RISCom/8 multiport card,
which gives you many serial ports. You would need something like
@@ -273,7 +273,7 @@
config SPECIALIX
tristate "Specialix IO8+ card support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN
help
This is a driver for the Specialix IO8+ multiport card (both the
ISA and the PCI version) which gives you many serial ports. You
@@ -297,7 +297,7 @@
config SX
tristate "Specialix SX (and SI) card support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
help
This is a driver for the SX and SI multiport serial cards.
Please read the file <file:Documentation/sx.txt> for details.
@@ -308,7 +308,7 @@
config RIO
tristate "Specialix RIO system support"
- depends on SERIAL_NONSTANDARD
+ depends on SERIAL_NONSTANDARD && BROKEN_ON_SMP
help
This is a driver for the Specialix RIO, a smart serial card which
drives an outboard box that can support up to 128 ports. Product
@@ -337,7 +337,7 @@
config STALLION
tristate "Stallion EasyIO or EC8/32 support"
- depends on STALDRV
+ depends on STALDRV && BROKEN
help
If you have an EasyIO or EasyConnection 8/32 multiport Stallion
card, then this is for you; say Y. Make sure to read
@@ -350,7 +350,7 @@
config ISTALLION
tristate "Stallion EC8/64, ONboard, Brumby support"
- depends on STALDRV
+ depends on STALDRV && BROKEN
help
If you have an EasyConnection 8/64, ONboard, Brumby or Stallion
serial multiport card, say Y here. Make sure to read
@@ -363,7 +363,7 @@
config SERIAL_TX3912
bool "TMPTX3912/PR31700 serial port support"
- depends on SERIAL_NONSTANDARD && MIPS
+ depends on SERIAL_NONSTANDARD && MIPS && BROKEN_ON_SMP
help
The TX3912 is a Toshiba RISC processor based o the MIPS 3900 core;
see <http://www.toshiba.com/taec/components/Generic/risc/tx3912.htm>.
@@ -423,7 +423,7 @@
config A2232
tristate "Commodore A2232 serial support (EXPERIMENTAL)"
- depends on EXPERIMENTAL && ZORRO
+ depends on EXPERIMENTAL && ZORRO && BROKEN_ON_SMP
---help---
This option supports the 2232 7-port serial card shipped with the
Amiga 2000 and other Zorro-bus machines, dating from 1989. At
@@ -907,6 +907,7 @@
config FTAPE
tristate "Ftape (QIC-80/Travan) support"
+ depends on BROKEN_ON_SMP
---help---
If you have a tape drive that is connected to your floppy
controller, say Y here.
--- linux-2.6.0-test2-full/drivers/char/generic_serial.c.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/char/generic_serial.c 2003-07-28 22:25:21.000000000 +0200
@@ -25,6 +25,7 @@
#include <linux/serial.h>
#include <linux/mm.h>
#include <linux/generic_serial.h>
+#include <linux/interrupt.h>
#include <asm/semaphore.h>
#include <asm/uaccess.h>
--- linux-2.6.0-test2-full/drivers/scsi/Kconfig.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/scsi/Kconfig 2003-07-29 10:57:31.000000000 +0200
@@ -355,7 +355,7 @@
# All the I2O code and drivers do not seem to be 64bit safe.
config SCSI_DPT_I2O
tristate "Adaptec I2O RAID support "
- depends on !X86_64 && SCSI
+ depends on !X86_64 && SCSI && BROKEN
help
This driver supports all of Adaptec's I2O based RAID controllers as
well as the DPT SmartRaid V cards. This is an Adaptec maintained
@@ -398,7 +398,7 @@
# does not use pci dma and seems to be onboard only for old machines
config SCSI_AM53C974
tristate "AM53/79C974 PCI SCSI support"
- depends on X86 && PCI && SCSI
+ depends on X86 && PCI && SCSI && BROKEN
---help---
This is support for the AM53/79C974 SCSI host adapters. Please read
<file:Documentation/scsi/AM53C974.txt> for details. Also, the
@@ -455,7 +455,7 @@
config SCSI_CPQFCTS
tristate "Compaq Fibre Channel 64-bit/66Mhz HBA support"
- depends on PCI && SCSI
+ depends on PCI && SCSI && BROKEN
help
Say Y here to compile in support for the Compaq StorageWorks Fibre
Channel 64-bit/66Mhz Host Bus Adapter.
@@ -626,7 +626,7 @@
config SCSI_GENERIC_NCR5380_MMIO
tristate "Generic NCR5380/53c400 SCSI MMIO support"
- depends on ISA && SCSI
+ depends on ISA && SCSI && (BROKEN || !SCSI_GENERIC_NCR5380)
---help---
This is a driver for the old NCR 53c80 series of SCSI controllers
on boards using memory mapped I/O.
@@ -742,7 +742,7 @@
config SCSI_INITIO
tristate "Initio 9100U(W) support"
- depends on PCI && SCSI
+ depends on PCI && SCSI && BROKEN
help
This is support for the Initio 91XXU(W) SCSI host adapter. Please
read the SCSI-HOWTO, available from
@@ -1161,7 +1161,7 @@
config SCSI_MCA_53C9X
tristate "NCR MCA 53C9x SCSI support"
- depends on MCA && SCSI
+ depends on MCA && SCSI && BROKEN_ON_SMP
help
Some MicroChannel machines, notably the NCR 35xx line, use a SCSI
controller based on the NCR 53C94. This driver will allow use of
@@ -1189,7 +1189,7 @@
config SCSI_PCI2000
tristate "PCI2000 support"
- depends on PCI && SCSI
+ depends on PCI && SCSI && BROKEN
help
This is support for the PCI2000I EIDE interface card which acts as a
SCSI host adapter. Please read the SCSI-HOWTO, available from
@@ -1202,7 +1202,7 @@
config SCSI_PCI2220I
tristate "PCI2220i support"
- depends on PCI && SCSI
+ depends on PCI && SCSI && BROKEN
help
This is support for the PCI2220i EIDE interface card which acts as a
SCSI host adapter. Please read the SCSI-HOWTO, available from
@@ -1314,7 +1314,7 @@
config SCSI_SEAGATE
tristate "Seagate ST-02 and Future Domain TMC-8xx SCSI support"
- depends on X86 && ISA && SCSI
+ depends on X86 && ISA && SCSI && BROKEN
---help---
These are 8-bit SCSI controllers; the ST-01 is also supported by
this driver. It is explained in section 3.9 of the SCSI-HOWTO,
@@ -1381,7 +1381,7 @@
config SCSI_DC390T
tristate "Tekram DC390(T) and Am53/79C974 SCSI support"
- depends on PCI && SCSI
+ depends on PCI && SCSI && BROKEN
---help---
This driver supports PCI SCSI host adapters based on the Am53C974A
chip, e.g. Tekram DC390(T), DawiControl 2974 and some onboard
--- linux-2.6.0-test2-full/drivers/mtd/devices/Kconfig.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/mtd/devices/Kconfig 2003-07-28 22:25:21.000000000 +0200
@@ -102,7 +102,7 @@
config MTD_BLKMTD
tristate "MTD emulation using block device"
- depends on MTD
+ depends on MTD && BROKEN
help
This driver allows a block device to appear as an MTD. It would
generally be used in the following cases:
--- linux-2.6.0-test2-full/drivers/ide/Kconfig.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/ide/Kconfig 2003-07-28 22:25:21.000000000 +0200
@@ -213,7 +213,31 @@
say M here and read <file:Documentation/modules.txt>. The module
will be called ide-cd.
-#dep_tristate ' Include IDE/ATAPI TAPE support' CONFIG_BLK_DEV_IDETAPE $CONFIG_BLK_DEV_IDE
+config BLK_DEV_IDETAPE
+ tristate "Include IDE/ATAPI TAPE support"
+ depends on BLK_DEV_IDE && BROKEN
+ help
+ If you have an IDE tape drive using the ATAPI protocol, say Y.
+ ATAPI is a newer protocol used by IDE tape and CD-ROM drives,
+ similar to the SCSI protocol. If you have an SCSI tape drive
+ however, you can say N here.
+
+ You should also say Y if you have an OnStream DI-30 tape drive; this
+ will not work with the SCSI protocol, until there is support for the
+ SC-30 and SC-50 versions.
+
+ If you say Y here, the tape drive will be identified at boot time
+ along with other IDE devices, as "hdb" or "hdc", or something
+ similar, and will be mapped to a character device such as "ht0"
+ (check the boot messages with dmesg). Be sure to consult the
+ <file:drivers/ide/ide-tape.c> and <file:Documentation/ide.txt> files
+ for usage information.
+
+ If you want to compile the driver as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want),
+ say M here and read <file:Documentation/modules.txt>. The module
+ will be called ide-tape.o.
+
config BLK_DEV_IDEFLOPPY
tristate "Include IDE/ATAPI FLOPPY support"
depends on BLK_DEV_IDE
--- linux-2.6.0-test2-full/drivers/atm/Kconfig.old 2003-07-29 00:07:40.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/atm/Kconfig 2003-07-29 00:08:56.000000000 +0200
@@ -145,7 +145,7 @@
config ATM_ZATM
tristate "ZeitNet ZN1221/ZN1225"
- depends on PCI && ATM
+ depends on PCI && ATM && BROKEN_ON_SMP
help
Driver for the ZeitNet ZN1221 (MMF) and ZN1225 (UTP-5) 155 Mbps ATM
adapters.
@@ -253,7 +253,7 @@
config ATM_AMBASSADOR
tristate "Madge Ambassador (Collage PCI 155 Server)"
- depends on PCI && ATM
+ depends on PCI && ATM && BROKEN_ON_SMP
help
This is a driver for ATMizer based ATM card produced by Madge
Networks Ltd. Say Y (or M to compile as a module named ambassador)
--- linux-2.6.0-test2-full/drivers/cdrom/Kconfig.old 2003-07-29 00:22:00.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/cdrom/Kconfig 2003-07-29 00:28:11.000000000 +0200
@@ -74,7 +74,7 @@
config SBPCD
tristate "Matsushita/Panasonic/Creative, Longshine, TEAC CDROM support"
- depends on CD_NO_IDESCSI
+ depends on CD_NO_IDESCSI && BROKEN_ON_SMP
---help---
This driver supports most of the drives which use the Panasonic or
Sound Blaster interface. Please read the file
@@ -199,7 +199,7 @@
config CM206
tristate "Philips/LMS CM206 CDROM support"
- depends on CD_NO_IDESCSI
+ depends on CD_NO_IDESCSI && BROKEN_ON_SMP
---help---
If you have a Philips/LMS CD-ROM drive cm206 in combination with a
cm260 host adapter card, say Y here. Please also read the file
@@ -245,7 +245,7 @@
config CDU31A
tristate "Sony CDU31A/CDU33A CDROM support"
- depends on CD_NO_IDESCSI
+ depends on CD_NO_IDESCSI && BROKEN_ON_SMP
---help---
These CD-ROM drives have a spring-pop-out caddyless drawer, and a
rectangular green LED centered beneath it. NOTE: these CD-ROM
@@ -267,7 +267,7 @@
config CDU535
tristate "Sony CDU535 CDROM support"
- depends on CD_NO_IDESCSI
+ depends on CD_NO_IDESCSI && BROKEN_ON_SMP
---help---
This is the driver for the older Sony CDU-535 and CDU-531 CD-ROM
drives. Please read the file <file:Documentation/cdrom/sonycd535>.
--- linux-2.6.0-test2-full/fs/partitions/Kconfig.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/fs/partitions/Kconfig 2003-07-28 22:25:22.000000000 +0200
@@ -29,6 +29,7 @@
config ACORN_PARTITION_EESOX
bool "EESOX partition support" if PARTITION_ADVANCED && ACORN_PARTITION
+ depends on BROKEN
default y if !PARTITION_ADVANCED && ARCH_ACORN
config ACORN_PARTITION_ICS
--- linux-2.6.0-test2-full/sound/oss/Kconfig.old 2003-07-28 22:23:21.000000000 +0200
+++ linux-2.6.0-test2-full/sound/oss/Kconfig 2003-07-28 22:25:22.000000000 +0200
@@ -912,7 +912,7 @@
config SOUND_AWE32_SYNTH
tristate "AWE32 synth"
- depends on SOUND_OSS
+ depends on SOUND_OSS && (!ISAPNP || BROKEN)
help
Say Y here if you have a Sound Blaster SB32, AWE32-PnP, SB AWE64 or
similar sound card. See <file:Documentation/sound/oss/README.awe>,
--- linux-2.6.0-test2-full/init/Kconfig.old 2003-07-28 22:23:22.000000000 +0200
+++ linux-2.6.0-test2-full/init/Kconfig 2003-07-29 10:14:28.000000000 +0200
@@ -34,6 +34,10 @@
endmenu
+config BROKEN_ON_SMP
+ bool
+ depends on BROKEN || !SMP
+ default y
menu "General setup"
Hi Adrian.
> - I do prefer BROKEN, Alan prefers OBSOLETE
> a s/BROKEN/OBSOLETE/g is acceptable for me
To me at least, BROKEN and OBSOLETE have different meanings,
and choice of which to use should depend on the circumstances.
Here's my choice of definitions for the cases that I can see:
* Driver has been replaced by a newer driver, and the old
driver is currently retained for cases that don't yet
work with the replacement. Driver will be removed in a
future kernel once the replacement handles all reported
cases.
CONFIG_OBSOLETE
* Driver is for hardware that is not supported in modern
computers, and is retained for use with older computers
only. Driver will not be removed, but is not expected to
be compiled by most users.
CONFIG_ANTIQUE
* Driver does not work, and is thus disabled. If it is not
fixed in the near future, it will be considered to be
OBSOLETE as well.
CONFIG_BROKEN
* Driver works on uniprocessor but not on SMP and is thus
disabled when compiling for SMP. It is assumed that the
driver will be fixed for SMP if relevant.
CONFIG_BROKEN_ON_SMP
* Driver was BROKEN some considerable number of releases
ago, and has never been fixed. It is thus assumed that
the driver is for some device that none of the kernel
developers is using. The driver will be removed in the
transition to the next major release if it retains this
status.
CONFIG_BROKEN && CONFIG_OBSOLETE
Personally, I'd like to see CONFIG_ANTIQUE (defaulting to "n")
as a dependency for all drivers matching the description above
simply to cut down on the amount of irrelevant choices in the
configuration process.
Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 24-Jul-2003
> > - I do prefer BROKEN, Alan prefers OBSOLETE
> > a s/BROKEN/OBSOLETE/g is acceptable for me
>
> To me at least, BROKEN and OBSOLETE have different meanings,
> and choice of which to use should depend on the circumstances.
I totally agree.
> Here's my choice of definitions for the cases that I can see:
>
> * Driver has been replaced by a newer driver, and the old
> driver is currently retained for cases that don't yet
> work with the replacement. Driver will be removed in a
> future kernel once the replacement handles all reported
> cases.
>
> CONFIG_OBSOLETE
Infact, all you need to justify CONFIG_OBSOLETE is:
The driver _will_ be removed in a future kernel.
I.E. it has been decided for whatever reason, that it is going, but
too many people still rely on it. This could be because there is a
replacement, there is no known physical hardware in existance, or it
is very old, and nobody uses it anybody - E.G. if a serious bug has
gone unnoticed for 2 major kernel revisions.
> * Driver is for hardware that is not supported in modern
> computers, and is retained for use with older computers
> only. Driver will not be removed, but is not expected to
> be compiled by most users.
>
> CONFIG_ANTIQUE
No need for this - either it works, or doesn't. If nobody uses it for
a long time, it becomes a candidate for CONFIG_OBSOLETE.
> * Driver does not work, and is thus disabled. If it is not
> fixed in the near future, it will be considered to be
> OBSOLETE as well.
>
> CONFIG_BROKEN
Please do _NOT_ do this - there is a far more important and worthwhile
reason to have a CONFIG_BROKEN than to simply save the few minutes of
inconvenience that including a non-compiling option in a kernel build
causes.
Imagine the situation where a driver such as a SCSI driver builds
successfully, but it silently corrupts data under certain, (possibly
rare), circumstances.
In that case, it's important to warn people that it's broken, because
it's not necessarily obvious, and could case significant data loss.
If something doesn't compile, it already gives you an error message.
The only problem is a few minutes of wasted time.
> * Driver works on uniprocessor but not on SMP and is thus
> disabled when compiling for SMP. It is assumed that the
> driver will be fixed for SMP if relevant.
>
> CONFIG_BROKEN_ON_SMP
Please _don't_ do this either. It implies that if
CONFIG_BROKEN_ON_SMP isn't set, then it's SMP safe - a lot of drivers
will NOT have been tested on SMP, so it's a bad thing to assume that
is the case.
> * Driver was BROKEN some considerable number of releases
> ago, and has never been fixed. It is thus assumed that
> the driver is for some device that none of the kernel
> developers is using. The driver will be removed in the
> transition to the next major release if it retains this
> status.
>
> CONFIG_BROKEN && CONFIG_OBSOLETE
See above for CONFIG_BROKEN.
> Personally, I'd like to see CONFIG_ANTIQUE (defaulting to "n")
> as a dependency for all drivers matching the description above
> simply to cut down on the amount of irrelevant choices in the
> configuration process.
Why? Some of us are more interested in what _doesn't_ compile.
Adding layers of abstraction often appears to help in the short term,
but for experienced users, it often just gets in the way.
John.
On Wed, Jul 30, 2003 at 10:11:17AM +0100, John Bradford wrote:
>...
> > * Driver does not work, and is thus disabled. If it is not
> > fixed in the near future, it will be considered to be
> > OBSOLETE as well.
> >
> > CONFIG_BROKEN
>
> Please do _NOT_ do this - there is a far more important and worthwhile
> reason to have a CONFIG_BROKEN than to simply save the few minutes of
> inconvenience that including a non-compiling option in a kernel build
> causes.
>
> Imagine the situation where a driver such as a SCSI driver builds
> successfully, but it silently corrupts data under certain, (possibly
> rare), circumstances.
>
> In that case, it's important to warn people that it's broken, because
> it's not necessarily obvious, and could case significant data loss.
> If something doesn't compile, it already gives you an error message.
> The only problem is a few minutes of wasted time.
You forget one important thing:
If a _user_ of a stable kernel notices "it doesn't even compile" this
gives a very bad impression of the quality of the Linux kernel.
> > * Driver works on uniprocessor but not on SMP and is thus
> > disabled when compiling for SMP. It is assumed that the
> > driver will be fixed for SMP if relevant.
> >
> > CONFIG_BROKEN_ON_SMP
>
> Please _don't_ do this either. It implies that if
> CONFIG_BROKEN_ON_SMP isn't set, then it's SMP safe - a lot of drivers
> will NOT have been tested on SMP, so it's a bad thing to assume that
> is the case.
>...
My patch adds BROKEN_ON_SMP only to drivers that don't compile, but if a
driver causes e.g. data corruption on SMP I don't see a reason against
letting it depend on BROKEN_ON_SMP.
> John.
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
> > > * Driver does not work, and is thus disabled. If it is not
> > > fixed in the near future, it will be considered to be
> > > OBSOLETE as well.
> > >
> > > CONFIG_BROKEN
> >
> > Please do _NOT_ do this - there is a far more important and worthwhile
> > reason to have a CONFIG_BROKEN than to simply save the few minutes of
> > inconvenience that including a non-compiling option in a kernel build
> > causes.
> >
> > Imagine the situation where a driver such as a SCSI driver builds
> > successfully, but it silently corrupts data under certain, (possibly
> > rare), circumstances.
> >
> > In that case, it's important to warn people that it's broken, because
> > it's not necessarily obvious, and could case significant data loss.
> > If something doesn't compile, it already gives you an error message.
> > The only problem is a few minutes of wasted time.
>
> You forget one important thing:
> If a _user_ of a stable kernel notices "it doesn't even compile" this
> gives a very bad impression of the quality of the Linux kernel.
I don't agree. The stock kernel is a work in progress, and things get
broken from time to time as a normal part of development. Experienced
users will realise that, and I wouldn't encourage inexperienced users
to compile their own kernel from the stock trees anyway, because they
could easily miss bugfixes, including data corruption and security
ones, simply because they assume that they are in the mainline
kernel.
Compiling your own kernel from the stock kernel trees is still
something that should be considered for experienced users only.
Besides, what's worse? Possible data corruption or a bad impression?
> > > * Driver works on uniprocessor but not on SMP and is thus
> > > disabled when compiling for SMP. It is assumed that the
> > > driver will be fixed for SMP if relevant.
> > >
> > > CONFIG_BROKEN_ON_SMP
> >
> > Please _don't_ do this either. It implies that if
> > CONFIG_BROKEN_ON_SMP isn't set, then it's SMP safe - a lot of drivers
> > will NOT have been tested on SMP, so it's a bad thing to assume that
> > is the case.
> >...
>
> My patch adds BROKEN_ON_SMP only to drivers that don't compile, but if a
> driver causes e.g. data corruption on SMP I don't see a reason against
> letting it depend on BROKEN_ON_SMP.
The name BROKEN_ON_SMP implies that if you don't set it, what's left
is known to work on SMP. In a lot of cases, it'll actually be
untested on SMP.
John.
On Wed, Jul 30, 2003 at 12:29:55PM +0100, John Bradford wrote:
> > > > * Driver does not work, and is thus disabled. If it is not
> > > > fixed in the near future, it will be considered to be
> > > > OBSOLETE as well.
> > > >
> > > > CONFIG_BROKEN
> > >
> > > Please do _NOT_ do this - there is a far more important and worthwhile
> > > reason to have a CONFIG_BROKEN than to simply save the few minutes of
> > > inconvenience that including a non-compiling option in a kernel build
> > > causes.
> > >
> > > Imagine the situation where a driver such as a SCSI driver builds
> > > successfully, but it silently corrupts data under certain, (possibly
> > > rare), circumstances.
> > >
> > > In that case, it's important to warn people that it's broken, because
> > > it's not necessarily obvious, and could case significant data loss.
> > > If something doesn't compile, it already gives you an error message.
> > > The only problem is a few minutes of wasted time.
> >
> > You forget one important thing:
> > If a _user_ of a stable kernel notices "it doesn't even compile" this
> > gives a very bad impression of the quality of the Linux kernel.
>
> I don't agree. The stock kernel is a work in progress, and things get
> broken from time to time as a normal part of development. Experienced
> users will realise that, and I wouldn't encourage inexperienced users
> to compile their own kernel from the stock trees anyway, because they
> could easily miss bugfixes, including data corruption and security
> ones, simply because they assume that they are in the mainline
> kernel.
Whether you like it or not:
Many non-kernel-hackers compile their own kernels.
Even if you wouldn't encourage them, there are enough situations where
they can't choose:
It occurs often that a fix or support for some hardware is only in the
latest -pre or in the -ac tree.
You say "things get broken from time to time as a normal part of
development". Ideally this should never happen in a stable series. We
don't live in an ideal world, but we should try to be as close as
possible to this goal.
> Compiling your own kernel from the stock kernel trees is still
> something that should be considered for experienced users only.
>
> Besides, what's worse? Possible data corruption or a bad impression?
Possible data corruption is worse, but completely disabling this driver
is even better.
> > > > * Driver works on uniprocessor but not on SMP and is thus
> > > > disabled when compiling for SMP. It is assumed that the
> > > > driver will be fixed for SMP if relevant.
> > > >
> > > > CONFIG_BROKEN_ON_SMP
> > >
> > > Please _don't_ do this either. It implies that if
> > > CONFIG_BROKEN_ON_SMP isn't set, then it's SMP safe - a lot of drivers
> > > will NOT have been tested on SMP, so it's a bad thing to assume that
> > > is the case.
> > >...
> >
> > My patch adds BROKEN_ON_SMP only to drivers that don't compile, but if a
> > driver causes e.g. data corruption on SMP I don't see a reason against
> > letting it depend on BROKEN_ON_SMP.
>
> The name BROKEN_ON_SMP implies that if you don't set it, what's left
> is known to work on SMP. In a lot of cases, it'll actually be
> untested on SMP.
Say which other drivers are completely broken on SMP without a fix
available or in the near future and it's easy to add a BROKEN_ON_SMP.
As long as noone reports such a bug I assume a driver works.
> John.
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
All,
I've been pondering this a bit. Perhaps you're trying to put a status on
drivers and other things at the wrong place.
In a bit more abstract way, the status (experimental, antique, broken or
whatever status you like) of a driver is not (should not be) related to
build dependencies. I think.
Perhaps something different is needed to maintain this status?
Obviously, it is necessary to display this status in the kernel config
tools. And probably the user should be able to filter certain statuses
(like: I don't want to see drivers that do not compile).
just my thoughts.
-- Jan Evert
PS: this is my opinion, not necessarily that of (atos)euronext.
Adrian Bunk wrote:
> On Wed, Jul 30, 2003 at 12:29:55PM +0100, John Bradford wrote:
>
>>>>> * Driver does not work, and is thus disabled. If it is not
>>>>> fixed in the near future, it will be considered to be
>>>>> OBSOLETE as well.
>>>>>
>>>>> CONFIG_BROKEN
>>>>
>>>>Please do _NOT_ do this - there is a far more important and worthwhile
>>>>reason to have a CONFIG_BROKEN than to simply save the few minutes of
>>>>inconvenience that including a non-compiling option in a kernel build
>>>>causes.
>>>>
>>>>Imagine the situation where a driver such as a SCSI driver builds
>>>>successfully, but it silently corrupts data under certain, (possibly
>>>>rare), circumstances.
>>>>
>>>>In that case, it's important to warn people that it's broken, because
>>>>it's not necessarily obvious, and could case significant data loss.
>>>>If something doesn't compile, it already gives you an error message.
>>>>The only problem is a few minutes of wasted time.
>>>
>>>You forget one important thing:
>>>If a _user_ of a stable kernel notices "it doesn't even compile" this
>>>gives a very bad impression of the quality of the Linux kernel.
>>
>>I don't agree. The stock kernel is a work in progress, and things get
>>broken from time to time as a normal part of development. Experienced
>>users will realise that, and I wouldn't encourage inexperienced users
>>to compile their own kernel from the stock trees anyway, because they
>>could easily miss bugfixes, including data corruption and security
>>ones, simply because they assume that they are in the mainline
>>kernel.
>
>
> Whether you like it or not:
>
> Many non-kernel-hackers compile their own kernels.
>
>
> Even if you wouldn't encourage them, there are enough situations where
> they can't choose:
>
> It occurs often that a fix or support for some hardware is only in the
> latest -pre or in the -ac tree.
>
>
> You say "things get broken from time to time as a normal part of
> development". Ideally this should never happen in a stable series. We
> don't live in an ideal world, but we should try to be as close as
> possible to this goal.
>
>
>
>>Compiling your own kernel from the stock kernel trees is still
>>something that should be considered for experienced users only.
>>
>>Besides, what's worse? Possible data corruption or a bad impression?
>
>
> Possible data corruption is worse, but completely disabling this driver
> is even better.
>
>
>>>>> * Driver works on uniprocessor but not on SMP and is thus
>>>>> disabled when compiling for SMP. It is assumed that the
>>>>> driver will be fixed for SMP if relevant.
>>>>>
>>>>> CONFIG_BROKEN_ON_SMP
>>>>
>>>>Please _don't_ do this either. It implies that if
>>>>CONFIG_BROKEN_ON_SMP isn't set, then it's SMP safe - a lot of drivers
>>>>will NOT have been tested on SMP, so it's a bad thing to assume that
>>>>is the case.
>>>>...
>>>
>>>My patch adds BROKEN_ON_SMP only to drivers that don't compile, but if a
>>>driver causes e.g. data corruption on SMP I don't see a reason against
>>>letting it depend on BROKEN_ON_SMP.
>>
>>The name BROKEN_ON_SMP implies that if you don't set it, what's left
>>is known to work on SMP. In a lot of cases, it'll actually be
>>untested on SMP.
>
>
> Say which other drivers are completely broken on SMP without a fix
> available or in the near future and it's easy to add a BROKEN_ON_SMP.
>
> As long as noone reports such a bug I assume a driver works.
>
>
>>John.
>
>
> cu
> Adrian
>
> [[email protected]]
>
> If a _user_ of a stable kernel notices "it doesn't even compile" this
> gives a very bad impression of the quality of the Linux kernel.
The keyword in this sentence is "stable."
Could you maybe come up with this again at around 2.6.40? :)
--
Tomas Szepe <[email protected]>
On Wed, Jul 30, 2003 at 06:04:03PM +0200, Tomas Szepe wrote:
> > [[email protected]]
> >
> > If a _user_ of a stable kernel notices "it doesn't even compile" this
> > gives a very bad impression of the quality of the Linux kernel.
>
> The keyword in this sentence is "stable."
> Could you maybe come up with this again at around 2.6.40? :)
The first stable kernel of the 2.6 kernel series will be 2.6.0.
My patch or omething similar should go into 2.6 before 2.6.0 .
Whether 2.6.0-test2 or 2.6.0-test15 is the right time is a different
question - as long as it's before 2.6.0 .
> Tomas Szepe <[email protected]>
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
> [[email protected]]
>
> On Wed, Jul 30, 2003 at 06:04:03PM +0200, Tomas Szepe wrote:
> > > [[email protected]]
> > >
> > > If a _user_ of a stable kernel notices "it doesn't even compile" this
> > > gives a very bad impression of the quality of the Linux kernel.
> >
> > The keyword in this sentence is "stable."
> > Could you maybe come up with this again at around 2.6.40? :)
>
> The first stable kernel of the 2.6 kernel series will be 2.6.0.
There are going to be a zillion drivers that don't compile by the
time 2.6.0 is released, which is precisely when lkml will see a whole
new wave of people willing to fix things so I really don't think
hiding the problems behind CONFIG_BROKEN or whatever is reasonable.
--
Tomas Szepe <[email protected]>
> > > > If a _user_ of a stable kernel notices "it doesn't even compile" this
> > > > gives a very bad impression of the quality of the Linux kernel.
> > >
> > > The keyword in this sentence is "stable."
> > > Could you maybe come up with this again at around 2.6.40? :)
> >
> > The first stable kernel of the 2.6 kernel series will be 2.6.0.
>
> There are going to be a zillion drivers that don't compile by the
> time 2.6.0 is released, which is precisely when lkml will see a whole
> new wave of people willing to fix things so I really don't think
> hiding the problems behind CONFIG_BROKEN or whatever is reasonable.
They would simply stay behind CONFIG_BROKEN for longer, because fewer
people would test them.
Also, remember that some things might only give compile errors under
certain circumstances. The _vast_ majority of kernels include TCP/IP
support, for example, so something that breaks when it's not
configured could easily go unnoticed for ages - does that mean it
should be put behind CONFIG_BROKEN when it's discovered?
John.
On Thu, Jul 31, 2003 at 11:15:25AM +0200, Tomas Szepe wrote:
> > [[email protected]]
> >
> > On Wed, Jul 30, 2003 at 06:04:03PM +0200, Tomas Szepe wrote:
> > > > [[email protected]]
> > > >
> > > > If a _user_ of a stable kernel notices "it doesn't even compile" this
> > > > gives a very bad impression of the quality of the Linux kernel.
> > >
> > > The keyword in this sentence is "stable."
> > > Could you maybe come up with this again at around 2.6.40? :)
> >
> > The first stable kernel of the 2.6 kernel series will be 2.6.0.
>
> There are going to be a zillion drivers that don't compile by the
> time 2.6.0 is released, which is precisely when lkml will see a whole
> new wave of people willing to fix things so I really don't think
> hiding the problems behind CONFIG_BROKEN or whatever is reasonable.
Note that we aren't talking about problems that ae easy to fix, such
problems are already fixed. We are talking about drivers that are broken
for many months.
Besides this, "a whole new wave of people willing to fix things" isn't
necessarily positive - for several of the broken drivers there were
alredy broken "fixes" posted. Some of these drivers need a non-trivial
fix by someone who knows what he is doing.
> Tomas Szepe <[email protected]>
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
On Thu, Jul 31, 2003 at 10:41:16AM +0100, John Bradford wrote:
>...
> Also, remember that some things might only give compile errors under
> certain circumstances. The _vast_ majority of kernels include TCP/IP
> support, for example, so something that breaks when it's not
> configured could easily go unnoticed for ages - does that mean it
> should be put behind CONFIG_BROKEN when it's discovered?
Most such issues aren't hard to fix once they are discovered.
Most broken drivers in 2.6 are different: They need a big amount of
non-trivial work to get them fixed.
> John.
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
On Thu, 31 Jul 2003, Tomas Szepe wrote:
> There are going to be a zillion drivers that don't compile by the
> time 2.6.0 is released, which is precisely when lkml will see a whole
> new wave of people willing to fix things so I really don't think
> hiding the problems behind CONFIG_BROKEN or whatever is reasonable.
I can't follow your logic. This is now supposed to be a stable kernel, but
you want to have a bunch of non-working drivers available to reduce
confidence in it? If I have device X, why do you think I would need a
driver less if it were marked BROKEN? A broken list would be a great
starting point for people who are looking for something to do in 2.6.
If you get a bunch of compiler errors without a clear indication that the
driver is known to have problems, it is more likely to produce a "Linux is
crap" reaction. With the problems Windows is showing this week, I'd like
to show Linux as the reliable alternative, not whatever MS is saying about
hacker code this week.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, Aug 13, 2003 at 10:50:12AM -0400, Bill Davidsen wrote:
> On Thu, 31 Jul 2003, Tomas Szepe wrote:
>
> > There are going to be a zillion drivers that don't compile by the
> > time 2.6.0 is released, which is precisely when lkml will see a whole
> > new wave of people willing to fix things so I really don't think
> > hiding the problems behind CONFIG_BROKEN or whatever is reasonable.
>
> I can't follow your logic. This is now supposed to be a stable kernel, but
> you want to have a bunch of non-working drivers available to reduce
> confidence in it? If I have device X, why do you think I would need a
> driver less if it were marked BROKEN? A broken list would be a great
> starting point for people who are looking for something to do in 2.6.
>
> If you get a bunch of compiler errors without a clear indication that the
> driver is known to have problems, it is more likely to produce a "Linux is
> crap" reaction. With the problems Windows is showing this week, I'd like
> to show Linux as the reliable alternative, not whatever MS is saying about
> hacker code this week.
The people who want Linux to be reliable won't be compiling their own
kernels, typically. Because, the people that _do_ compile their own
kernels have sense enough to disable broken drivers :) That's what Red
Hat, SuSE, and others do today.
Jeff
On Wed, Aug 13, 2003 at 11:31:45AM -0400, Jeff Garzik wrote:
> On Wed, Aug 13, 2003 at 10:50:12AM -0400, Bill Davidsen wrote:
>...
> > If you get a bunch of compiler errors without a clear indication that the
> > driver is known to have problems, it is more likely to produce a "Linux is
> > crap" reaction. With the problems Windows is showing this week, I'd like
> > to show Linux as the reliable alternative, not whatever MS is saying about
> > hacker code this week.
>
> The people who want Linux to be reliable won't be compiling their own
> kernels, typically. Because, the people that _do_ compile their own
> kernels have sense enough to disable broken drivers :) That's what Red
> Hat, SuSE, and others do today.
It occurs quite often that you need e.g. the latest -pre or -ac to
support some of your hardware.
These are situations when an average systems administrator has to
compile his on kernel.
> Jeff
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
> > The people who want Linux to be reliable won't be compiling their own
> > kernels, typically. Because, the people that _do_ compile their own
> > kernels have sense enough to disable broken drivers :) That's what Red
> > Hat, SuSE, and others do today.
>
> It occurs quite often that you need e.g. the latest -pre or -ac to
> support some of your hardware.
>
> These are situations when an average systems administrator has to
> compile his on kernel.
That is true. The point is that I don't see how adding an arbitrary
dependency on a CONFIG_BROKEN option actually helps in any way.
Presumably a system administrator who is compiling a -pre or -ac
kernel from kernel.org for a _production_ system is only going to
include drivers that are actually required. If any of those don't
compile, there is a problem anyway. If they are hidden under a
CONFIG_BROKEN option, it's just an extra step to enable them, then
compile with them enabled to get an error to post to LKML.
If something is really necessary, why not simply include an ! in the
description of any option that is known not to compile?
John.
On Wed, Aug 13, 2003 at 09:40:07PM +0100, John Bradford wrote:
> > > The people who want Linux to be reliable won't be compiling their own
> > > kernels, typically. Because, the people that _do_ compile their own
> > > kernels have sense enough to disable broken drivers :) That's what Red
> > > Hat, SuSE, and others do today.
> >
> > It occurs quite often that you need e.g. the latest -pre or -ac to
> > support some of your hardware.
> >
> > These are situations when an average systems administrator has to
> > compile his on kernel.
>
> That is true. The point is that I don't see how adding an arbitrary
> dependency on a CONFIG_BROKEN option actually helps in any way.
>...
> compile, there is a problem anyway. If they are hidden under a
> CONFIG_BROKEN option, it's just an extra step to enable them, then
> compile with them enabled to get an error to post to LKML.
>...
You don't accidentially enable such an option.
Currently, I see every day reports about compile errors on
linux-kernel - reports for errors that are known and unfixed since
several months.
A dependency on BROKEN is a clear mark that a compile error is already
known.
My personal opinions:
- Ideally, every valid configuration should result in a kernel that
both compiles and works.
- Every compile error gives a bad impression of the quality of the
Linux kernel.
Current 2.4 kernels are (on i386) relatively near to this ideal.
It's not only a technical aspect, it's also a marketing aspect. With
many broken drivers it's easy for people to argue against Linux using
arguments like
Look, what a crap Linux is, the developers even care whether the
kernel compiles.
> John.
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
On Wed, 13 Aug 2003, Jeff Garzik wrote:
> On Wed, Aug 13, 2003 at 10:50:12AM -0400, Bill Davidsen wrote:
> > If you get a bunch of compiler errors without a clear indication that the
> > driver is known to have problems, it is more likely to produce a "Linux is
> > crap" reaction. With the problems Windows is showing this week, I'd like
> > to show Linux as the reliable alternative, not whatever MS is saying about
> > hacker code this week.
>
> The people who want Linux to be reliable won't be compiling their own
> kernels, typically. Because, the people that _do_ compile their own
> kernels have sense enough to disable broken drivers :) That's what Red
> Hat, SuSE, and others do today.
Disabling broken drivers is fine, identifying them is nice, too. When I
was deciding which gigE cards to use, I found that all drivers in the 2.4
kernel were not equal. Some didn't compile with my config, some compiled
but had runtime problems, etc.
It would be nice if there were some neat 3-D shreadsheet type thing
listing all drivers, all architectures, UP vs. SMP, and a status such as
WORKS, DOESN'T COMPILE, REPORTED PROBLEMS (SLOW|ERRORS|PANICS) and the
like. I don't even know where to find a good open source 3-D spreadsheet,
and the data certainly is scattered enough to be a project in itself,
chasing a moving target.
A BROKEN config isn't a perfect solution (fixing the drivers is), but it
would help in some cases, and I don't see that it would hurt, and more
information is usually better.
Not my original idea, my ego won't be hurt if it doesn't happen.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
If the user is ignorant to the point that an error message whilst
compiling a development kernel, (I.E. any kernel from kernel.org),
would cause them to think:
> Look, what a crap Linux is, the developers even care whether the
> kernel compiles.
they are forming an opinion of Linux based on things they don't
understand. That's ignorance, and CONFIG_BROKEN won't fix that.
John.
On Wednesday 13 August 2003 17:06, Bill Davidsen wrote:
> It would be nice if there were some neat 3-D shreadsheet type thing
> listing all drivers, all architectures, UP vs. SMP, and a status such as
> WORKS, DOESN'T COMPILE, REPORTED PROBLEMS (SLOW|ERRORS|PANICS) and the
> like. I don't even know where to find a good open source 3-D spreadsheet,
> and the data certainly is scattered enough to be a project in itself,
> chasing a moving target.
You are aware that this would probably take more effort to keep up to date
than the code itself, right? And that one spreadsheet couldn't
simultaneously be accurate for 2.4, 2.6, -ac, -mm, -redhat, -suse...
And how would you keep track of weird "there's a good driver for that, but you
have to apply this patch" cases? (Isn't this sort of thing what the various
bug database efforts are for?)
Will you be tracking cases that only show up on big-endian 64 bit platforms
that have more than one PCI bus? How about situations where the driver works
fine except when you use it in a system with a certain type of USB controller
and do not have a PS/2 mouse plugged into the system. (Yes, really.) How
about if it works but doesn't come back after an APM suspend? Do you tag it
as broken if it works on 95% of the systems out there, but not all of them,
based on stuff the Bios did before the Linux kernel even got loaded?
I'm currently trying to figure out why APM doesn't work on my new thinkpad.
Is APM broken? It freezes my thinkpad solid. The exact same Red Hat 9
kernel worked fine on the toshiba that got rained on...
I'm now playing with software suspend in 2.6-test. You not only have to
enable software suspend in the power management menu, and you have to go into
ACPI and enable ACPI support, but you also have to enable ACPI sleep state
support. Right. Documentation/swsusp.txt didn't mention that, and there's a
kconfig dependency missing here somewhere. I'm much more interested in
getting it to work than marking it broken for posterity...
Rob
> > It would be nice if there were some neat 3-D shreadsheet type thing
> > listing all drivers, all architectures, UP vs. SMP, and a status such as
> > WORKS, DOESN'T COMPILE, REPORTED PROBLEMS (SLOW|ERRORS|PANICS) and the
> > like. I don't even know where to find a good open source 3-D spreadsheet,
> > and the data certainly is scattered enough to be a project in itself,
> > chasing a moving target.
>
> You are aware that this would probably take more effort to keep up to date
> than the code itself, right? And that one spreadsheet couldn't
> simultaneously be accurate for 2.4, 2.6, -ac, -mm, -redhat, -suse...
>
> And how would you keep track of weird "there's a good driver for that, but you
> have to apply this patch" cases? (Isn't this sort of thing what the various
> bug database efforts are for?)
I implemented a spreadsheet-type display of which kernel versions
worked, didn't work, were untestable, and had patches available, in my
bug database, for each bug report. The display looks good but I've
never really found it particularly useful :-).
John.
On Sun, 17 Aug 2003, Rob Landley wrote:
> On Wednesday 13 August 2003 17:06, Bill Davidsen wrote:
>
> > It would be nice if there were some neat 3-D shreadsheet type thing
> > listing all drivers, all architectures, UP vs. SMP, and a status such as
> > WORKS, DOESN'T COMPILE, REPORTED PROBLEMS (SLOW|ERRORS|PANICS) and the
> > like. I don't even know where to find a good open source 3-D spreadsheet,
> > and the data certainly is scattered enough to be a project in itself,
> > chasing a moving target.
>
> You are aware that this would probably take more effort to keep up to date
> than the code itself, right? And that one spreadsheet couldn't
> simultaneously be accurate for 2.4, 2.6, -ac, -mm, -redhat, -suse...
Did you miss the "It would be nice" and "a project in itself?" I am aware
of the issues, I was hoping someone would tell me that there was a tool
which did all this already (bugkeeper?) or suggest some path to a useful
subset with a manageable resource cost.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.