This is a proof of concept at the moment, but if the corner cases
can be sorted out, then this might be the best way to replace
the defconfig functionality. This patch implements Linus' idea
for using Kconfig fragments to replicate the *_defconfig functionality
Essentially, this patch adds a new <board>_defconfig target that is
processed if a <board>.Kconfig file is present in the $(ARCH)/configs
directory instead of the current <board>_defconfig file. The target
works by passing the $(ARCH)/configs/<board>.Kconfig to Kconfig
instead of the architecture's default $(ARCH)/Kconfig file.
<board>.Kconfig defines new board specific config items (prefixed with
"generateconfig_" which default to 'y' or 'm' and select the options
that the platform cares about. It also then either the architecture
default Kconfig, or another Kconfig fragment that includes the default
one (therefore the fragments can be 'stacked' to include, say, default
options for the architecture, or particular chipset).
This patch includes sample Kconfig fragments for the PowerPC 83xx and
5200 platforms to demonstrate the concept, but it should work in exactly
the same way for ARM or any other architecture. With the sample,
'mpc5200_defconfig', 'mpc83xx_defconfig' and even 'ppc32_defconfig' are
all valid targets (although the ppc32_defconfig won't actually include
any particular board support).
An interesting side effect of this approach is that it can be used to
'overlay' the configuration for a board over top of the existing config.
I went ahead and added the %_oldconfig option to do this which could
be useful for building a kernel that supports multiple boards, or for
adding in a set of debug options.
Another advantage of this approach is that it doesn't immediately
eliminate the old defconfig files so that platforms can be migrated to
this new method one at a time.
Current problems:
- I haven't figured out a way for the fragment to force an option to
be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
This may require changing the syntax.
- It still doesn't resolve dependencies. A solver would help with this.
For the time being I work around the problem by running the generated
config through 'oldconfig' and looking for differences. If the files
differ (ignoring comments and generateconfig_* options) after oldconfig,
then the <board>_defconfig target returns a failure. (but leaves the
new .config intact so the user can resolve it with menuconfig). This
way at least the user is told when a Kconfig fragment is invalid.
Signed-off-by: Grant Likely <[email protected]>
---
arch/powerpc/configs/mpc5200.Kconfig | 24 +++++++++++++++++++++
arch/powerpc/configs/mpc83xx.Kconfig | 35 +++++++++++++++++++++++++++++++
arch/powerpc/configs/ppc32.Kconfig | 39 ++++++++++++++++++++++++++++++++++
scripts/kconfig/Makefile | 18 +++++++++++++++-
4 files changed, 115 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/configs/mpc5200.Kconfig
create mode 100644 arch/powerpc/configs/mpc83xx.Kconfig
create mode 100644 arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc5200.Kconfig b/arch/powerpc/configs/mpc5200.Kconfig
new file mode 100644
index 0000000..1281dd1
--- /dev/null
+++ b/arch/powerpc/configs/mpc5200.Kconfig
@@ -0,0 +1,24 @@
+config generateconfig_MPC5200_YES
+ def_bool y
+ select PPC_MPC52xx
+ select PPC_MPC5200_SIMPLE
+ select PPC_EFIKA
+ select PPC_LITE5200
+ select PPC_MEDIA5200
+ select PPC_MPC5200_BUGFIX
+ select PPC_MPC5200_GPIO
+ select PPC_MPC5200_LPBFIFO
+ select PPC_BESTCOMM
+ select SIMPLE_GPIO
+ select SERIAL_MPC52xx
+ select SERIAL_MPC52xx_CONSOLE
+ select MTD
+ select PATA_MPC52xx
+ select SPI_MPC52xx
+ select SPI_MPC52xx_PSC
+ select I2C_MPC
+ select FEC_MPC52xx
+ select LXT_PHY
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc83xx.Kconfig b/arch/powerpc/configs/mpc83xx.Kconfig
new file mode 100644
index 0000000..818fdec
--- /dev/null
+++ b/arch/powerpc/configs/mpc83xx.Kconfig
@@ -0,0 +1,35 @@
+config generateconfig_MPC83xx_YES
+ def_bool y
+ select PPC_83xx
+ select EMBEDDED
+ select MPC831x_RDB
+ select MPC832x_MDS
+ select MPC832x_RDB
+ select MPC834x_MDS
+ select MPC834x_ITX
+ select MPC836x_MDS
+ select MPC836x_RDK
+ select MPC837x_MDS
+ select MPC837x_RDB
+ select SBC834x
+ select ASP834x
+ select QUICC_ENGINE
+ select OE_GPIO
+ select MATH_EMULATION
+ select SATA_FSL
+ select SATA_SIL
+ select MARVELL_PHY
+ select DAVICOM_PHY
+ select VITESSE_PHY
+ select ICPLUS_PHY
+ select FIXED_PHY
+ select FSL_PQ_MDIO
+ select GIANFAR
+ select UCC_GETH
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select I2C_MPC
+ select GPIOLIB
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/ppc32.Kconfig b/arch/powerpc/configs/ppc32.Kconfig
new file mode 100644
index 0000000..66e39f0
--- /dev/null
+++ b/arch/powerpc/configs/ppc32.Kconfig
@@ -0,0 +1,39 @@
+config generateconfig_PPC32_YES
+ def_bool y
+ select EXPERIMENTAL
+ select DEVTMPFS
+ select PPC32
+ select SYSVIPC
+ select BLK_DEV_INITRD
+ select NO_HZ
+ select HIGH_RES_TIMERS
+ select GPIO
+ select SPI
+ select SPI_SPIDEV
+ select I2C
+ select I2C_CHARDEV
+ select USB
+ select NET
+ select SCSI
+ select BLK_DEV_SD
+ select ATA
+ select PACKET
+ select UNIX
+ select INET
+ select IP_MULTICAST
+ select IP_PNP
+ select IP_PNP_DHCP
+ select NETDEVICES
+ select NET_ETHERNET
+ select PROC_DEVICETREE
+ select INOTIFY
+ select TMPFS
+ select NFS_FS
+ select ROOT_NFS
+ select PRINTK_TIME
+
+config generateconfig_PPC32_MODULE
+ def_tristate m
+
+source arch/powerpc/Kconfig
+
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 7ea649d..4e9afd9 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,7 +117,23 @@ else
$(Q)$< -D arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
endif
-%_defconfig: $(obj)/conf
+# New-style defconfig using Kconfig fragments
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -D /dev/null arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)sed '/^#/d;/^CONFIG_generateconfig_/d' $(objtree)/.config > $(objtree)/.config-diff1
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig test to make sure it doesn't change
+ $(Q)sed '/^#/d' $(objtree)/.config > $(objtree)/.config-diff2
+ $(Q)diff -u $(objtree)/.config-diff1 $(objtree)/.config-diff2
+
+# This is kind of useful. The new-style defconfig using Kconfig fragments
+# can also be used to successively pull in the options a defconfig cares
+# about overtop of the current config.
+%_oldconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -o arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig to clear out the temporary items
+
+# Old-style defconfig using full (or trimmed) .config files.
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%_defconfig
$(Q)$< -D arch/$(SRCARCH)/configs/$@ $(Kconfig)
# Help text used by make help
Typo correction:
2010/7/13 Grant Likely <[email protected]>:
[...]
> <board>.Kconfig defines new board specific config items (prefixed with
> "generateconfig_" which default to 'y' or 'm' and select the options
> that the platform cares about. ?It also then either the architecture
s/either the/either includes the/
> default Kconfig, or another Kconfig fragment that includes the default
> one (therefore the fragments can be 'stacked' to include, say, default
> options for the architecture, or particular chipset).
[...]
On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
> - I haven't figured out a way for the fragment to force an option to
> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> This may require changing the syntax.
> - It still doesn't resolve dependencies. A solver would help with this.
> For the time being I work around the problem by running the generated
> config through 'oldconfig' and looking for differences. If the files
> differ (ignoring comments and generateconfig_* options) after oldconfig,
> then the <board>_defconfig target returns a failure. (but leaves the
> new .config intact so the user can resolve it with menuconfig). This
> way at least the user is told when a Kconfig fragment is invalid.
The solver would fix the whole issues with the defconfigs , we wouldn't
need this Kconfig change .. From my perspective we shouldn't be fooling
around with anything but the solver approach ..
It just doesn't feel like Kconfig was meant to do this, it feel like
somewhat of an abuse ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <[email protected]> wrote:
> On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
>
>> - I haven't figured out a way for the fragment to force an option to
>> ? be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
>> ? This may require changing the syntax.
>> - It still doesn't resolve dependencies. ?A solver would help with this.
>> ? For the time being I work around the problem by running the generated
>> ? config through 'oldconfig' and looking for differences. ?If the files
>> ? differ (ignoring comments and generateconfig_* options) after oldconfig,
>> ? then the <board>_defconfig target returns a failure. ?(but leaves the
>> ? new .config intact so the user can resolve it with menuconfig). ?This
>> ? way at least the user is told when a Kconfig fragment is invalid.
>
> The solver would fix the whole issues with the defconfigs , we wouldn't
> need this Kconfig change .. From my perspective we shouldn't be fooling
> around with anything but the solver approach ..
The solver would complement Kconfig fragments, but it doesn't
implement all the functionality. For instance, it doesn't help a
board config picking up a bunch of options from an SoC or Architecture
config file, especially things that are developer/maintainer choices
as opposed to hard requirements). Solver on its own is an incremental
improvement over what we currently have, but it doesn't solve the
whole problem.
> It just doesn't feel like Kconfig was meant to do this, it feel like
> somewhat of an abuse ..
Why? It uses the Kconfig language itself to specify additional
constraints on the final configuration. Seems to be the essence of
elegance to me. :-)
g.
On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <[email protected]> wrote:
> > On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
> >
> >> - I haven't figured out a way for the fragment to force an option to
> >> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> >> This may require changing the syntax.
> >> - It still doesn't resolve dependencies. A solver would help with this.
> >> For the time being I work around the problem by running the generated
> >> config through 'oldconfig' and looking for differences. If the files
> >> differ (ignoring comments and generateconfig_* options) after oldconfig,
> >> then the <board>_defconfig target returns a failure. (but leaves the
> >> new .config intact so the user can resolve it with menuconfig). This
> >> way at least the user is told when a Kconfig fragment is invalid.
> >
> > The solver would fix the whole issues with the defconfigs , we wouldn't
> > need this Kconfig change .. From my perspective we shouldn't be fooling
> > around with anything but the solver approach ..
>
> The solver would complement Kconfig fragments, but it doesn't
> implement all the functionality. For instance, it doesn't help a
> board config picking up a bunch of options from an SoC or Architecture
> config file, especially things that are developer/maintainer choices
> as opposed to hard requirements). Solver on its own is an incremental
> improvement over what we currently have, but it doesn't solve the
> whole problem.
I don't understand what your saying here.. Imagine a defconfig that you
have now only drastically smaller. The solver picks the stuff that
doesn't exist already in the defconfig. You would just apply the solver
to whatever is in the defconfig.
Then that allows us to keep the current defconfig format without mass
converting to something else. It's would also be built on a solver that
helps with other issues within Kconfig.
> > It just doesn't feel like Kconfig was meant to do this, it feel like
> > somewhat of an abuse ..
>
> Why? It uses the Kconfig language itself to specify additional
> constraints on the final configuration. Seems to be the essence of
> elegance to me. :-)
To my mind the only problem with the current defconfig formatting is the
size of the files. If those files are 5-10 lines instead of 2000 lines,
then I think the readability problem isn't really an issue any more..
The point of using Kconfig was the readability..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Tue, 13 Jul 2010, Daniel Walker wrote:
> On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> > On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <[email protected]> wrote:
> > > It just doesn't feel like Kconfig was meant to do this, it feel like
> > > somewhat of an abuse ..
> >
> > Why? It uses the Kconfig language itself to specify additional
> > constraints on the final configuration. Seems to be the essence of
> > elegance to me. :-)
>
> To my mind the only problem with the current defconfig formatting is the
> size of the files. If those files are 5-10 lines instead of 2000 lines,
> then I think the readability problem isn't really an issue any more..
That's one issue indeed.
But there is another issue that is somewhat related, which is to be able
to categorize config options.
Currently the defconfig files carry information about the proper driver
to enable in order to support devices soldered on the board and
therefore which are not "optional". That might be a particular RTC
chip, or a particular ethernet block integrated into a SOC, etc. Of
course we want to preserve the ability to disable support for those
things, but by default people want to have all the right drivers
selected for all the built-in hardware when selecting a target
machine/board without having to dig into a datasheet for that target.
The defconfig files also carry config options that are totally
arbitrary. What type of filesystem, what kind of network protocol, what
USB device drivers (not host controller driver), what amount of
debugging options, all those are unrelated to the actual hardware and
may vary from one user to another.
Furthermore, in order to reduce the number of defconfig files, we tried
to combine as many targets into a single kernel image. That increases
build test coverage with fewer builds which is good, but then the info
about specific drivers required for a specific target but not for
another target in the same defconfig is now lost. It is therefore quite
hard to produce a highly optimized configuration for a single target
without doing some digging again.
So it is really in the Kconfig file that all those hardware specific
options can be expressed in a clear and readable way. When BOARD_XYZ is
selected and STD_CONFIG is selected, then automatically select RTC_FOO,
select ETH_BAR, select LED_BAZ, etc. Of course we would want required
dependencies to be automatically selected as well.
But all the rest is arbitrary and could be part of common shared
profiles or the like in defconfig format.
Nicolas
On Tue, 2010-07-13 at 20:07 -0400, Nicolas Pitre wrote:
> That's one issue indeed.
>
> But there is another issue that is somewhat related, which is to be able
> to categorize config options.
>
> Currently the defconfig files carry information about the proper driver
> to enable in order to support devices soldered on the board and
> therefore which are not "optional". That might be a particular RTC
> chip, or a particular ethernet block integrated into a SOC, etc. Of
> course we want to preserve the ability to disable support for those
> things, but by default people want to have all the right drivers
> selected for all the built-in hardware when selecting a target
> machine/board without having to dig into a datasheet for that target.
>
> The defconfig files also carry config options that are totally
> arbitrary. What type of filesystem, what kind of network protocol, what
> USB device drivers (not host controller driver), what amount of
> debugging options, all those are unrelated to the actual hardware and
> may vary from one user to another.
Right.
> Furthermore, in order to reduce the number of defconfig files, we tried
> to combine as many targets into a single kernel image. That increases
> build test coverage with fewer builds which is good, but then the info
> about specific drivers required for a specific target but not for
> another target in the same defconfig is now lost. It is therefore quite
> hard to produce a highly optimized configuration for a single target
> without doing some digging again.
>
> So it is really in the Kconfig file that all those hardware specific
> options can be expressed in a clear and readable way. When BOARD_XYZ is
> selected and STD_CONFIG is selected, then automatically select RTC_FOO,
> select ETH_BAR, select LED_BAZ, etc. Of course we would want required
> dependencies to be automatically selected as well.
I see..
> But all the rest is arbitrary and could be part of common shared
> profiles or the like in defconfig format.
I'm sure most people will want to have a config isolated to their
specific device. That to me seems reasonable because everyone wants the
smallest possible kernel they can get for their given device.
Then there would be a smaller group who wants to create multi-device
images. I don't see this being the average users tho, or kernel hackers.
To me there is little difference between doing,
CONFIG_ARCH_MSM=y
or
select ARCH_MSM
they are basically doing the same thing. So doing anything in Kconfig is
a lateral move .. Converting over to Kconfig in this case doesn't makes
sense to me.
Could we do something more like adding an "#include" option into the
defconfigs .. Then you could create defconfigs that hold multiple
devices without a massive rework to what we currently have.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
> - It still doesn't resolve dependencies. A solver would help with this.
> For the time being I work around the problem by running the generated
> config through 'oldconfig' and looking for differences. If the files
> differ (ignoring comments and generateconfig_* options) after oldconfig,
> then the <board>_defconfig target returns a failure. (but leaves the
> new .config intact so the user can resolve it with menuconfig). This
> way at least the user is told when a Kconfig fragment is invalid.
It's not a solver but I'm pushing a patch to warn on selecting symbols
with unmet dependencies so that you can select further symbols (manual
solving). The patch is in linux-next but you also can grab it from:
http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
--
Catalin
On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
<[email protected]> wrote:
> On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>> - It still doesn't resolve dependencies. ?A solver would help with this.
>> ? For the time being I work around the problem by running the generated
>> ? config through 'oldconfig' and looking for differences. ?If the files
>> ? differ (ignoring comments and generateconfig_* options) after oldconfig,
>> ? then the <board>_defconfig target returns a failure. ?(but leaves the
>> ? new .config intact so the user can resolve it with menuconfig). ?This
>> ? way at least the user is told when a Kconfig fragment is invalid.
>
> It's not a solver but I'm pushing a patch to warn on selecting symbols
> with unmet dependencies so that you can select further symbols (manual
> solving). The patch is in linux-next but you also can grab it from:
>
> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
sfr and I were talking about your patch the other day. Just warning
on incomplete dependencies is enough to make it actually workable for
me (without my ugly post-processing step). I was very happy to hear
that it is in linux-next.
Last missing piece is being able to do "select FOO = n", which Stephen
is currently working on.
g.
On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
I thought Linus' idea was to use:
KBUILD_KCONFIG=file make allnoconfig
in which case any option which would be presented to the user which hasn't
been selected by 'file' ends up being set to n. That means there's no
need for a special "select FOO=n" construct.
See one of Linus' replies on June 3:
Message-ID: <[email protected]>
On Fri, Jul 16, 2010 at 11:07 AM, Russell King - ARM Linux
<[email protected]> wrote:
>
> I thought Linus' idea was to use:
>
> KBUILD_KCONFIG=file make allnoconfig
See an earlier reply - that is indeed what I suggested, and yes, it
avoids the need to be able to "unselect" things.
However, it turns out that even then you do want to extend the Kconfig
language with the ability to select particular values. Not for boolean
(or even tristate things), but for things that select an integer or
string value etc.
So the "select OPTION=xyz" syntax ends up being a good thing even for
the "-n" (allnoconfig) case too.
And while I think the allnoconfig model has some advantages (the
Kconfig input file ends up being independent of the default values),
that very fact ends up being a disadvantage too (the Kconfig input
file likely ends up being larger, since _hopefully_ the defaults are
sane).
So I'm not at all married to the "allnoconfig" model. It's one way of
doing things, but I think the argument that we should start with the
defaults and modify those instead is not an invalid one.
Linus
On Fri, Jul 16, 2010 at 12:07 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
>> Last missing piece is being able to do "select FOO = n", which Stephen
>> is currently working on.
>
> I thought Linus' idea was to use:
>
> KBUILD_KCONFIG=file make allnoconfig
That was more a prototype of the idea; but it's a pretty cumbersome
user interface. :-) By changing the makefile to look for kconfig
fragments in the configs directory, the user interface for choosing a
config remains exactly the same.
As for the allnoconfig bit....
> in which case any option which would be presented to the user which hasn't
> been selected by 'file' ends up being set to n. ?That means there's no
> need for a special "select FOO=n" construct.
...Linus chimed in on this that he doesn't actually care much. I
think defconfig with an empty initial config file makes a lot more
sense than allnoconfig so that we're using the default values from the
normal Kconfig files.
> See one of Linus' replies on June 3:
> Message-ID: <[email protected]>
See this response:
Message-ID: <[email protected]>
http://news.gmane.org/find-root.php?message_id=%3cAANLkTik%2dQCXFnjma3J28B9h27uajOcDhthTGz99zKgVi%40mail.gmail.com%3e
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Fri, 16 Jul 2010, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
> <[email protected]> wrote:
> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
> >> - It still doesn't resolve dependencies. ?A solver would help with this.
> >> ? For the time being I work around the problem by running the generated
> >> ? config through 'oldconfig' and looking for differences. ?If the files
> >> ? differ (ignoring comments and generateconfig_* options) after oldconfig,
> >> ? then the <board>_defconfig target returns a failure. ?(but leaves the
> >> ? new .config intact so the user can resolve it with menuconfig). ?This
> >> ? way at least the user is told when a Kconfig fragment is invalid.
> >
> > It's not a solver but I'm pushing a patch to warn on selecting symbols
> > with unmet dependencies so that you can select further symbols (manual
> > solving). The patch is in linux-next but you also can grab it from:
> >
> > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
>
> sfr and I were talking about your patch the other day. Just warning
> on incomplete dependencies is enough to make it actually workable for
> me (without my ugly post-processing step). I was very happy to hear
> that it is in linux-next.
>
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
Instead of (or in addition to) warning for incomplete
dependencies, I'd much prefer if the prerequisites were recursively
selected automatically. This way if some options are moved inside a
submenu at some point with a config symbol for that subcategory
(e.g. CONFIG_NETDEV_1000), or if the subsystem is reorganized into
submodules that are required for some driver to work, then my
config will still be fine.
For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
smart enough to notice and automatically enable CONFIG_MTD and
CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
Nicolas
On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre <[email protected]> wrote:
> On Fri, 16 Jul 2010, Grant Likely wrote:
>
>> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
>> <[email protected]> wrote:
>> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>> >> - It still doesn't resolve dependencies. ?A solver would help with this.
>> >> ? For the time being I work around the problem by running the generated
>> >> ? config through 'oldconfig' and looking for differences. ?If the files
>> >> ? differ (ignoring comments and generateconfig_* options) after oldconfig,
>> >> ? then the <board>_defconfig target returns a failure. ?(but leaves the
>> >> ? new .config intact so the user can resolve it with menuconfig). ?This
>> >> ? way at least the user is told when a Kconfig fragment is invalid.
>> >
>> > It's not a solver but I'm pushing a patch to warn on selecting symbols
>> > with unmet dependencies so that you can select further symbols (manual
>> > solving). The patch is in linux-next but you also can grab it from:
>> >
>> > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f
>>
>> sfr and I were talking about your patch the other day. ?Just warning
>> on incomplete dependencies is enough to make it actually workable for
>> me (without my ugly post-processing step). ?I was very happy to hear
>> that it is in linux-next.
>>
>> Last missing piece is being able to do "select FOO = n", which Stephen
>> is currently working on.
>
> Instead of (or in addition to) warning for incomplete
> dependencies, I'd much prefer if the prerequisites were recursively
> selected automatically. ?This way if some options are moved inside a
> submenu at some point with a config symbol for that subcategory
> (e.g. CONFIG_NETDEV_1000), or if the subsystem is reorganized into
> submodules that are required for some driver to work, then my
> config will still be fine.
>
> For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> smart enough to notice and automatically enable CONFIG_MTD and
> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
I fully agree. However, the warnings make the system work now while
we wait for a full solver to be implemented.
g.
On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
> For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> smart enough to notice and automatically enable CONFIG_MTD and
> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
How do you sort out something like this:
config FOO
bool "Foo"
depends on (A && B) || C
Do you enable A and B, A, B and C or just C?
Bear in mind that A could be 'X86', 'M68K' or any other arch specific
symbol.
I prefer the warning method because it prompts you to investigate what's
changed and sort out the problem by ensuring that the appropriate symbols
are also selected. The automatic selection of dependencies method carries
the risk that it'll do the wrong thing with the above scenario.
On Fri, 16 Jul 2010, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre <[email protected]> wrote:
> > For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> > smart enough to notice and automatically enable CONFIG_MTD and
> > CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
>
> I fully agree. However, the warnings make the system work now while
> we wait for a full solver to be implemented.
Why can't the tool just _select_ the option it is warning about when a
dependency is not met? That shouldn't require a full solver.
Nicolas
On Fri, 16 Jul 2010, Russell King - ARM Linux wrote:
> On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
> > For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> > smart enough to notice and automatically enable CONFIG_MTD and
> > CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
>
> How do you sort out something like this:
>
> config FOO
> bool "Foo"
> depends on (A && B) || C
DOH.
Nicolas
On Fri, Jul 16, 2010 at 12:30 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
>> For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
>> smart enough to notice and automatically enable CONFIG_MTD and
>> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
>
> How do you sort out something like this:
>
> config FOO
> ? ? ? ?bool "Foo"
> ? ? ? ?depends on (A && B) || C
>
> Do you enable A and B, A, B and C or just C?
>
> Bear in mind that A could be 'X86', 'M68K' or any other arch specific
> symbol.
>
> I prefer the warning method because it prompts you to investigate what's
> changed and sort out the problem by ensuring that the appropriate symbols
> are also selected. ?The automatic selection of dependencies method carries
> the risk that it'll do the wrong thing with the above scenario.
Good point.
g.
On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <[email protected]> wrote:
>
> DOH.
Well, it's possible that the correct approach is a mixture.
Automatically do the trivial cases (recursive selects, dependencies
that are simple or of the form "x && y" etc), and warn about the cases
that aren't trivial (where "not trivial" may not necessarily be about
fundamentally ambiguous ones, but just "complex enough that I won't
even try").
Maybe a full "solver" is unnecessary, for example, but just a simple
"automatically enable the direct dependencies and scream when it's not
simple any more" would take care of 99% of the common cases, and then
warn when it needs some manual help.
So it's not a strict "one or the other" issue. The solution could be
"some of both".
Linus
On Friday 16 July 2010 19:57:55 Grant Likely wrote:
> On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
> <[email protected]> wrote:
> > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
>
> sfr and I were talking about your patch the other day. Just warning
> on incomplete dependencies is enough to make it actually workable for
> me (without my ugly post-processing step). I was very happy to hear
> that it is in linux-next.
>
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
Are there a lot of symbols for which this is needed? If there is only
a handful, you could work around this by selectively adding
config FOO
bool "foo"
default !FOO_DISABLE
config FOO_DISABLE
def_bool "n"
Arnd
On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <[email protected]> wrote:
> >
> > DOH.
>
> Well, it's possible that the correct approach is a mixture.
>
> Automatically do the trivial cases (recursive selects, dependencies
> that are simple or of the form "x && y" etc), and warn about the cases
> that aren't trivial (where "not trivial" may not necessarily be about
> fundamentally ambiguous ones, but just "complex enough that I won't
> even try").
There is still a risk with this approach when the Kconfig isn't entirely
correct. For example, on ARM we have (I pushed a patch already):
config CPU_32v6K
depends on CPU_V6
config CPU_V7
select CPU_32v6K
In this simple approach, we end up selecting CPU_V6 when we only need
CPU_V7. There other places like this in the kernel.
Of course, kbuild could still warn but if people rely on this feature to
select options automatically I suspect they would ignore the warnings.
--
Catalin
On Friday 16 July 2010 20:46:17 Linus Torvalds wrote:
> Maybe a full "solver" is unnecessary, for example, but just a simple
> "automatically enable the direct dependencies and scream when it's not
> simple any more" would take care of 99% of the common cases, and then
> warn when it needs some manual help.
I think the recursion should also be limited to cases where the
dependency is a valid selectable option, i.e. not for
# this architecture does not support MMIO
config HAS_IOMEM
def_bool 'n'
config PCI
bool "PCI Device drivers"
depends on HAS_IOMEM
config FOO
tristate "Some device driver"
depends on PCI
In this case, it would be straightforward for the solver to enable PCI
for when something selects CONFIG_FOO, but it should print a warning
if this is attempted while HAS_IOMEM is unconditionally disabled,
since that puts it into the "not simple" category.
Arnd
On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
<[email protected]> wrote:
> On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
>> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <[email protected]> wrote:
>> >
>> > DOH.
>>
>> Well, it's possible that the correct approach is a mixture.
>>
>> Automatically do the trivial cases (recursive selects, dependencies
>> that are simple or of the form "x && y" etc), and warn about the cases
>> that aren't trivial (where "not trivial" may not necessarily be about
>> fundamentally ambiguous ones, but just "complex enough that I won't
>> even try").
>
> There is still a risk with this approach when the Kconfig isn't entirely
> correct. For example, on ARM we have (I pushed a patch already):
>
> config CPU_32v6K
> ? ? ? ?depends on CPU_V6
>
> config CPU_V7
> ? ? ? ?select CPU_32v6K
>
> In this simple approach, we end up selecting CPU_V6 when we only need
> CPU_V7. There other places like this in the kernel.
>
> Of course, kbuild could still warn but if people rely on this feature to
> select options automatically I suspect they would ignore the warnings.
In my first patch, I made Kconfig problems errors instead of warnings.
That would prevent people from ignoring them.
g.
On Fri, 16 Jul 2010, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
> <[email protected]> wrote:
> > On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
> >> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <[email protected]> wrote:
> >> >
> >> > DOH.
> >>
> >> Well, it's possible that the correct approach is a mixture.
> >>
> >> Automatically do the trivial cases (recursive selects, dependencies
> >> that are simple or of the form "x && y" etc), and warn about the cases
> >> that aren't trivial (where "not trivial" may not necessarily be about
> >> fundamentally ambiguous ones, but just "complex enough that I won't
> >> even try").
> >
> > There is still a risk with this approach when the Kconfig isn't entirely
> > correct. For example, on ARM we have (I pushed a patch already):
> >
> > config CPU_32v6K
> > ? ? ? ?depends on CPU_V6
> >
> > config CPU_V7
> > ? ? ? ?select CPU_32v6K
> >
> > In this simple approach, we end up selecting CPU_V6 when we only need
> > CPU_V7. There other places like this in the kernel.
> >
> > Of course, kbuild could still warn but if people rely on this feature to
> > select options automatically I suspect they would ignore the warnings.
>
> In my first patch, I made Kconfig problems errors instead of warnings.
> That would prevent people from ignoring them.
ACK.
Nicolas
On Fri, Jul 16, 2010 at 2:29 PM, Nicolas Pitre <[email protected]> wrote:
> On Fri, 16 Jul 2010, Grant Likely wrote:
>
>> On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
>> <[email protected]> wrote:
>> > On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
>> >> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <[email protected]> wrote:
>> >> >
>> >> > DOH.
>> >>
>> >> Well, it's possible that the correct approach is a mixture.
>> >>
>> >> Automatically do the trivial cases (recursive selects, dependencies
>> >> that are simple or of the form "x && y" etc), and warn about the cases
>> >> that aren't trivial (where "not trivial" may not necessarily be about
>> >> fundamentally ambiguous ones, but just "complex enough that I won't
>> >> even try").
>> >
>> > There is still a risk with this approach when the Kconfig isn't entirely
>> > correct. For example, on ARM we have (I pushed a patch already):
>> >
>> > config CPU_32v6K
>> > ? ? ? ?depends on CPU_V6
>> >
>> > config CPU_V7
>> > ? ? ? ?select CPU_32v6K
>> >
>> > In this simple approach, we end up selecting CPU_V6 when we only need
>> > CPU_V7. There other places like this in the kernel.
>> >
>> > Of course, kbuild could still warn but if people rely on this feature to
>> > select options automatically I suspect they would ignore the warnings.
>>
>> In my first patch, I made Kconfig problems errors instead of warnings.
>> ?That would prevent people from ignoring them.
>
> ACK.
It would also flush out any current Kconfig dependency issues.
g.
On Fri, 2010-07-16 at 21:17 +0100, Grant Likely wrote:
> On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
> <[email protected]> wrote:
> > On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
> >> On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre <[email protected]> wrote:
> >> >
> >> > DOH.
> >>
> >> Well, it's possible that the correct approach is a mixture.
> >>
> >> Automatically do the trivial cases (recursive selects, dependencies
> >> that are simple or of the form "x && y" etc), and warn about the cases
> >> that aren't trivial (where "not trivial" may not necessarily be about
> >> fundamentally ambiguous ones, but just "complex enough that I won't
> >> even try").
> >
> > There is still a risk with this approach when the Kconfig isn't entirely
> > correct. For example, on ARM we have (I pushed a patch already):
> >
> > config CPU_32v6K
> > depends on CPU_V6
> >
> > config CPU_V7
> > select CPU_32v6K
> >
> > In this simple approach, we end up selecting CPU_V6 when we only need
> > CPU_V7. There other places like this in the kernel.
> >
> > Of course, kbuild could still warn but if people rely on this feature to
> > select options automatically I suspect they would ignore the warnings.
>
> In my first patch, I made Kconfig problems errors instead of warnings.
> That would prevent people from ignoring them.
My point was that if we allow kbuild to select dependencies
automatically (as per Nico's initial suggestion, followed up by Linus),
in the above situation CPU_V7 would trigger the selection of CPU_V6 and
I don't want this. If we rely on such automatic selection of the
"depends on" options, we can't make the warnings be errors.
--
Catalin
Daniel Walker wrote:
> > But all the rest is arbitrary and could be part of common shared
> > profiles or the like in defconfig format.
>
> I'm sure most people will want to have a config isolated to their
> specific device. That to me seems reasonable because everyone wants the
> smallest possible kernel they can get for their given device.
Indeed, but people who want the smallest possible kernel for their
specific device _in a particular use context_ tend to want:
- To disable support for parts of the device they aren't using.
For example, an SoC with integrated ethernet that isn't actually
wired up on their board, or where they're using an external ethernet
chip instead for some reason.
- To choose what's modular and what isn't, even for integrated
parts. For example to control the bootup sequence, they might
want to delay integrated USB and IDE initialisation, which is done by
making those modular and loading them after bringing up a splash
screen earlier in the boot scripts.
So there is still a need to be able to override the drivers and
settings, but it's still incredibly useful to have defaults which
describe the SoC or board accurately.
-- Jamie
On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier <[email protected]> wrote:
> Daniel Walker wrote:
>> > But all the rest is arbitrary and could be part of common shared
>> > profiles or the like in defconfig format.
>>
>> I'm sure most people will want to have a config isolated to their
>> specific device. That to me seems reasonable because everyone wants the
>> smallest possible kernel they can get for their given device.
Just to be clear (specifically for me as a maintainer) the purpose of
defconfigs is not to provide the best optimized kernel configuration
for each given board. defconfigs are useful as a reasonable working
starting point, and to provide build coverage testing.
> Indeed, but people who want the smallest possible kernel for their
> specific device _in a particular use context_ tend to want:
>
> ?- To disable support for parts of the device they aren't using.
> ? ?For example, an SoC with integrated ethernet that isn't actually
> ? ?wired up on their board, or where they're using an external ethernet
> ? ?chip instead for some reason.
>
> ?- To choose what's modular and what isn't, even for integrated
> ? ?parts. ?For example to control the bootup sequence, they might
> ? ?want to delay integrated USB and IDE initialisation, which is done by
> ? ?making those modular and loading them after bringing up a splash
> ? ?screen earlier in the boot scripts.
>
> So there is still a need to be able to override the drivers and
> settings, but it's still incredibly useful to have defaults which
> describe the SoC or board accurately.
Yes. The defconfig is only a starting point. Maintaining the actual
config for the shipped kernel is the job of the distribution vendor
and I have zero interest in maintaining those configurations in the
kernel tree.
g.