Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier ja...@shareable.org 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas catalin.mari...@arm.com 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 11:07 AM, Russell King - ARM Linux li...@arm.linux.org.uk 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 12:07 PM, Russell King - ARM Linux li...@arm.linux.org.uk 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: alpine.lfd.2.00.1006031317410.8...@i5.linux-foundation.org See this response: Message-ID: aanlktik-qcxfnjma3j28b9h27uajocdhthtgz99zk...@mail.gmail.com 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, 16 Jul 2010, Grant Likely wrote: On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas catalin.mari...@arm.com 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 16 Jul 2010, Grant Likely wrote: On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas catalin.mari...@arm.com 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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: alpine.lfd.2.00.1006031317410.8...@i5.linux-foundation.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, 16 Jul 2010, Grant Likely wrote: On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre n...@fluxnic.net 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 12:30 PM, Russell King - ARM Linux li...@arm.linux.org.uk 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Friday 16 July 2010 19:57:55 Grant Likely wrote: On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas catalin.mari...@arm.com 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote: On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote: On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, 16 Jul 2010, Grant Likely wrote: On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote: On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, Jul 16, 2010 at 2:29 PM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 16 Jul 2010, Grant Likely wrote: On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote: On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Fri, 2010-07-16 at 21:17 +0100, Grant Likely wrote: On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote: On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 grant.lik...@secretlab.ca --- 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 000..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 000..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 +
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
Typo correction: 2010/7/13 Grant Likely grant.lik...@secretlab.ca: [...] 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). [...] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker dwal...@codeaurora.org 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 dwal...@codeaurora.org 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote: On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker dwal...@codeaurora.org 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
