could the [x86] Kconfig content for PCI be cleaned up at all?
digging through the current PCI code and Kconfig files and it seems
like some of that could be made simpler, but i'm willing to be convinced otherwise.
first, from arch/x86/Kconfig, rather than simply sourcing the file
"drivers/pci/Kconfig" (as is done with many other drivers directories), that Kconfig file defines:
menu "Bus options (PCI etc.)"
config PCI
bool "PCI support"
default y
... snip ...
and later on, sources the Kconfig files for PCI and PCIe individually:
source "drivers/pci/pcie/Kconfig"
source "drivers/pci/Kconfig"
and even further down, finally sources the file for PCI hotplug after PCMCIA:
source "drivers/pcmcia/Kconfig"
source "drivers/pci/hotplug/Kconfig"
given the dependencies, could all of this not be encapsulated in the top-level Kconfig files under drivers/pci?
next, in drivers/Makefile, pci code is pulled in with the single
statement:
obj-$(CONFIG_PCI) += pci/
given that, can't one drop all the "depends on PCI" directives from the file drivers/pci/Kconfig? or just wrap the whole file in a "if PCI" test? (unless there's something i'm missing here.)
and could the same thing not be said for the pcie/ subdirectory?drivers/pci/Makefile contains the line:
obj-$(CONFIG_PCIEPORTBUS) += pcie/
with the dependency in drivers/pci/pcie/Kconfig:
config PCIEPORTBUS
bool "PCI Express Port Bus support"
depends on PCI
suggesting that drivers/pci/pcie/Kconfig could also be simplified quite a bit by dropping redundant dependency directives.
thoughts?
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Bjorn Helgaas
maintainerQuoted 4 lines · Robert P. J. Day
digging through the current PCI code and
Kconfigfiles and it seems
like some of that could be made simpler, but i'm willing to be convinced otherwise.
I'm sure it could be cleaned up, and it would be great if you did!
I don't know the reason why all the arches source drivers/pci/pcie/Kconfig directly; it seems like that should be done from drivers/pci/Kconfig.
Quoted 43 lines
first, from
arch/x86/Kconfig, rather than simply sourcing the file
"drivers/pci/Kconfig" (as is done with many other drivers directories), thatKconfigfile defines:menu "Bus options (PCI etc.)"
config PCI
bool "PCI support"
default y
... snip ...and later on, sources the
Kconfigfiles for PCI and PCIe individually:source "
drivers/pci/pcie/Kconfig"source "
drivers/pci/Kconfig"and even further down, finally sources the file for PCI hotplug after PCMCIA:
source "
drivers/pcmcia/Kconfig"source "
drivers/pci/hotplug/Kconfig"given the dependencies, could all of this not be encapsulated in the top-level
Kconfigfiles underdrivers/pci?next, in
drivers/Makefile, pci code is pulled in with the single
statement:obj-$(CONFIG_PCI) += pci/given that, can't one drop all the "depends on PCI" directives from the file
drivers/pci/Kconfig? or just wrap the whole file in a "if PCI" test? (unless there's something i'm missing here.)and could the same thing not be said for the pcie/ subdirectory?
drivers/pci/Makefilecontains the line:obj-$(CONFIG_PCIEPORTBUS) += pcie/with the dependency in
drivers/pci/pcie/Kconfig:
Quoted 8 lines
config PCIEPORTBUS
bool "PCI Express Port Bus support"
depends on PCIsuggesting that
drivers/pci/pcie/Kconfigcould also be simplified quite a bit by dropping redundant dependency directives.thoughts?
I don't know all the history behind what we have now, so I can't give you much advice. I think you just have to work through the process of simplifying things and see whether it turns out to be feasible.
Bjorn
Quoted 11 lines · Bjorn Helgaas
Quoted 4 lines · Robert P. J. Day
digging through the current PCI code and
Kconfigfiles and it
seems like some of that could be made simpler, but i'm willing to be convinced otherwise.I'm sure it could be cleaned up, and it would be great if you did!
I don't know the reason why all the arches source
drivers/pci/pcie/Kconfigdirectly; it seems like that should be done fromdrivers/pci/Kconfig.
that's what i thought, but i'll look more closely to see if there's
some subtlety there.
at the very least, i can submit a patch for both:
* .../pci/Kconfig
* .../pci/pcie/Kconfig
that removes all the extraneous dependencies on PCI and PCIEPORTBUS, respectively, and just wraps the files in a single "if" condition, unless someone has a reason why that wouldn't work. you know, along the lines of acpi/Kconfig and many others:
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support" ... snip ...
if ACPI
... big snip, entire rest of file ...
endif # ACPI
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 35 lines · Bjorn Helgaas
Quoted 4 lines · Robert P. J. Day
digging through the current PCI code and
Kconfigfiles and it seems
like some of that could be made simpler, but i'm willing to be convinced otherwise.I'm sure it could be cleaned up, and it would be great if you did!
I don't know the reason why all the arches source
drivers/pci/pcie/Kconfigdirectly; it seems like that should be done fromdrivers/pci/Kconfig.Quoted 23 lines
first, from
arch/x86/Kconfig, rather than simply sourcing the file
"drivers/pci/Kconfig" (as is done with many other drivers directories), thatKconfigfile defines:menu "Bus options (PCI etc.)"
config PCI
bool "PCI support"
default y
... snip ...and later on, sources the
Kconfigfiles for PCI and PCIe individually:source "
drivers/pci/pcie/Kconfig"source "
drivers/pci/Kconfig"and even further down, finally sources the file for PCI hotplug after PCMCIA:
source "
drivers/pcmcia/Kconfig"source "
drivers/pci/hotplug/Kconfig"
... snip ...
Quoted 4 lines
I don't know all the history behind what we have now, so I can't give you much advice. I think you just have to work through the process of simplifying things and see whether it turns out to be feasible.
one of the quirky features of the current Kconfig layout is that, in
some arch Kconfig files, the main PCI content is included, then pcmcia, *then* PCI hotplug, which means that when you pop into something like "make menuconfig" and wander over to the PCI menu, you see the majority of PCI selections, then the selection for PCCard, and *then* the choice for PCI hotplug, which strikes me as just, well, odd and confusing since, if you deselect PCI entirely, almost everything goes away except for (you guessed it) PCCard. (and that framebuffer selection as well.)
as you say, there may be some historical inertia as to why things
were done this way, but is there any *technical* reason why everything PCI-related can't just hang off of the drivers/pci/ directory via a single "source" directive?
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Bjorn Helgaas
maintainerQuoted 55 lines · Robert P. J. Day
Quoted 6 lines · Bjorn Helgaas
Quoted 4 lines · Robert P. J. Day
digging through the current PCI code and
Kconfigfiles and it seems
like some of that could be made simpler, but i'm willing to be convinced otherwise.Quoted 29 lines
I'm sure it could be cleaned up, and it would be great if you did!
I don't know the reason why all the arches source
drivers/pci/pcie/Kconfigdirectly; it seems like that should be done fromdrivers/pci/Kconfig.Quoted 23 lines
first, from
arch/x86/Kconfig, rather than simply sourcing the file
"drivers/pci/Kconfig" (as is done with many other drivers directories), thatKconfigfile defines:menu "Bus options (PCI etc.)"
config PCI
bool "PCI support"
default y
... snip ...and later on, sources the
Kconfigfiles for PCI and PCIe individually:source "
drivers/pci/pcie/Kconfig"source "
drivers/pci/Kconfig"and even further down, finally sources the file for PCI hotplug after PCMCIA:
source "
drivers/pcmcia/Kconfig"source "
drivers/pci/hotplug/Kconfig"... snip ...Quoted 4 lines
I don't know all the history behind what we have now, so I can't give you much advice. I think you just have to work through the process of simplifying things and see whether it turns out to be feasible.
one of the quirky features of the current
Kconfiglayout is that, in
some archKconfigfiles, the main PCI content is included, then pcmcia, *then* PCI hotplug, which means that when you pop into something like "make menuconfig" and wander over to the PCI menu, you see the majority of PCI selections, then the selection for PCCard, and *then* the choice for PCI hotplug, which strikes me as just, well, odd and confusing since, if you deselect PCI entirely, almost everything goes away except for (you guessed it) PCCard. (and that framebuffer selection as well.)
Quoted 4 lines
as you say, there may be some historical inertia as to why things
were done this way, but is there any *technical* reason why everything PCI-related can't just hang off of thedrivers/pci/directory via a single "source" directive?
Not that I'm aware of. Give it a try and we'll see what happens.
Bjorn