drivers/Kconfig
RFC PATCH 1/1 drivers/Kconfig
What do people think about creating a common drivers/Kconfig that includes the drivers/*/Kconfig files? This saves quite a few superflous Kconfig lines and is a natural way to avoid the architectyures going out of sync. Yes, this requires every driver having proper bus-depencies but we should be almost there already.
Sample patch (for ppc, i386 and x86_64) attached.
arch/i386/Kconfig +3 -50
@@ -1175,61 +1175,14 @@ endmenu -source "drivers/base/Kconfig" - -source "drivers/mtd/Kconfig" - -source "drivers/parport/Kconfig" - -source "drivers/pnp/Kconfig" - -source "drivers/block/Kconfig" - -source "drivers/ide/Kconfig" - -source "drivers/scsi/Kconfig" - -source "drivers/cdrom/Kconfig" - -source "drivers/md/Kconfig" - -source "drivers/message/fusion/Kconfig" - -source "drivers/ieee1394/Kconfig" - -source "drivers/message/i2o/Kconfig" - source "net/Kconfig" - source "net/ax25/Kconfig" - source "net/irda/Kconfig" - -source "drivers/isdn/Kconfig" - -source "drivers/telephony/Kconfig" - -# -# input before char - char/joystick depends on it. As does USB. -# -source "drivers/input/Kconfig" - -source "drivers/char/Kconfig" - -#source drivers/misc/Config.in -source "drivers/media/Kconfig" - -source "fs/Kconfig" - -source "drivers/video/Kconfig" - -source "sound/Kconfig" - -source "drivers/usb/Kconfig" - source "net/bluetooth/Kconfig" - +source "fs/Kconfig" source "arch/i386/oprofile/Kconfig" +source "drivers/Kconfig" +source "sound/Kconfig" menu "Kernel hacking"
arch/ppc/Kconfig +1 -34
@@ -1021,8 +1021,6 @@ source "drivers/pcmcia/Kconfig" -source "drivers/parport/Kconfig" - endmenu menu "Advanced setup"
@@ -1120,39 +1118,13 @@ depends on ADVANCED_OPTIONS && 8xx endmenu -source "drivers/base/Kconfig" - -source "drivers/mtd/Kconfig" - -source "drivers/pnp/Kconfig" - -source "drivers/block/Kconfig" - -source "drivers/md/Kconfig" - -source "drivers/ide/Kconfig" - -source "drivers/scsi/Kconfig" - -source "drivers/message/fusion/Kconfig" - -source "drivers/ieee1394/Kconfig" - -source "drivers/message/i2o/Kconfig" - source "net/Kconfig" source "net/ax25/Kconfig" source "net/irda/Kconfig" -source "drivers/isdn/Kconfig" - -source "drivers/video/Kconfig" - -source "drivers/cdrom/Kconfig" - -source "drivers/input/Kconfig" +source "drivers/Kconfig" menu "Macintosh device drivers"
@@ -1289,9 +1261,6 @@ endmenu -source "drivers/char/Kconfig" - -source "drivers/media/Kconfig" source "fs/Kconfig"
@@ -1320,8 +1289,6 @@ default y endmenu - -source "drivers/usb/Kconfig" source "net/bluetooth/Kconfig"
arch/x86_64/Kconfig +1 -45
56 lines not on this page · raw message
drivers/message/i2o/Kconfig +2 -2
@@ -1,5 +1,6 @@ - +# Currently not 64-bit safe menu "I2O device support" + depends on !X86_64 config I2O tristate "I2O support"
@@ -78,4 +79,3 @@ here and read <file:Documentation/modules.txt>. endmenu -
Quoted 8 lines · Christoph Hellwig
What do people think about creating a common
drivers/Kconfigthat includes thedrivers/*/Kconfigfiles? This saves quite a few superflousKconfiglines and is a natural way to avoid the architectyures going out of sync. Yes, this requires every driver having proper bus-depencies but we should be almost there already.Sample patch (for ppc, i386 and
x86_64) attached.
Yes, this is the goal.
This won't be very useful to the more exotic architectures like S/390, which use almost none of drivers/* except for drivers/s390/*, so for non-PCI, non-ISA architectures I have a feeling that including drivers/Kconfig would be a waste.
Jeff