ARM defconfig files
in [Kernel]
|
Prev: menuconfig: fix to center checklist correctly in a corner case
Next: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y
From: Daniel Walker on 3 Jun 2010 16:10 On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote: > On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote: > > On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote: > > > On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote: > > > > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote: > > > > > > > > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > > > > > > > > > No amount of reorganising the Kconfig files into a heirarchial manner > > > > > > (which they already are) helps. Not one bit. Because they already are. > > > > > > That's not where the problem is. > > > > > > > > > > I don't think you read the whole thread. > > > > > > > > > > Earlier on, I explained exactly what I wanted: just add some "select" > > > > > statements to pickt he things you need per the particular target > > > > > configuration. You seem to have missed that part. > > > > > > > > > > In other words, you _can_ encode the information that is in the > > > > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do > > > > > it in a human-readable manner. And the hierarchical thing is absolutely > > > > > required for that - otherwise you'd end up with just another form of the > > > > > current xyz_defconfig. > > > > > > > > > > See? > > > > > > > > > > In other words, you should be able to basically use "make allnoconfig" > > > > > together with a Kconfig.xyz file input to select _exactly_ the pieces you > > > > > need, and nothing else. > > > > > > > > If you did this for drivers, what about disabling a driver? If we used > > > > "select" wouldn't that force all the drivers on without allowing it to > > > > be unselected? > > > > > > I already covered that in my (ignored) email where I brought up a > > > "STD_CONFIG" config symbol, which could be disabled to turn off all > > > these additional "select"s. > > > > I didn't ignore it, I guess I just didn't fully understand it .. > > > > So your saying it would drop all the selects, but keep the selected > > options in tact? Or it would just turn off all the selected options? > > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. I just did a little test, and it doesn't. Kconfig would un-select all the drivers, at least from my test. > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. If my test was correct we would need a new "select" variant that would leave the options turned on in order to get something equal to the current defconfigs. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 3 Jun 2010 16:20 On Thu, 3 Jun 2010, Russell King wrote: > > I already covered that in my (ignored) email where I brought up a > "STD_CONFIG" config symbol, which could be disabled to turn off all > these additional "select"s. I apparently haven't explained myself enough, because what you keep on harping on is not something I consider acceptable. STD_CONFIG is pointless. It's pointless because the solution to what you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz file at all. So when I suggest special Kconfig files, they are meant to just generate the templates - ie they'd _generate_ what is currently the defconfig files. You wouldn't _have_ to use them at all. If you _had_ to use them, you'd lose the flexibility of Kconfig and asking questions. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King on 3 Jun 2010 16:20 On Thu, Jun 03, 2010 at 01:06:48PM -0700, Daniel Walker wrote: > On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote: > > config MACH_HALIBUT > > bool "Halibut Board (QCT SURF7201A)" > > select I2C if STD_CONFIG > > select I2C_WHATEVER if STD_CONFIG > > ... > > > > That means if you enable STD_CONFIG, you'll get everything that's required > > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > > everything that was selected as still being selected. > > I just did a little test, and it doesn't. Kconfig would un-select all > the drivers, at least from my test. That's because it knows what the original state of the symbol is. Yes, that's a little undesirable for our behaviour - but it can be worked around - by saving and restarting Kconfig. Try this: config STD_CONFIG bool "Standard config" default y config DRIVER_A tristate "Driver A" config ARM def_bool y select DRIVER_A if STD_CONFIG and in a new directory /path/to/kernel/scripts/kconfig/mconf test.conf If you turn off STD_CONFIG immediately, it'll turn off DRIVER_A. However, save out the config, and re-run mconf test.conf. You'll then find that DRIVER_A remains set even when STD_CONFIG is turned off. So, Kconfig does have the behaviour we desire but it's not directly accessible. Is it worth persuing? Will Linus accept this STD_CONFIG idea or did his lack of reply to it indicate that he's not something he's willing to entertain? In any case, this is my last mail on the subject. I won't be replying to mail for at least the next four days. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nicolas Pitre on 3 Jun 2010 16:30 On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote: > > So your saying it would drop all the selects, but keep the selected > > options in tact? Or it would just turn off all the selected options? > > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. > > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. I think this certainly makes sense, at least as a proof of concept. If we end up with lots of select XYZ if STD_CONFIG then at that point it might be a good idea to introduce some variations in the Kconfig language directly. Something like a multi-priority select statement that would either: - provide the minimum amount of choice to the user and forcefully "select" a default set of options expected to enable all features of the target hardware, or - let the user see the "preselected" options with a chance to turn it off, but provide a y by default right away, or - ignore those "preselect" statement entirely, as some expert mode. Of course the 2nd and 3rd options wouldn't necessarily mean an optimal or even working kernel configuration would be produced. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nicolas Pitre on 3 Jun 2010 16:40
On Thu, 3 Jun 2010, Linus Torvalds wrote: > > > On Thu, 3 Jun 2010, Russell King wrote: > > > > I already covered that in my (ignored) email where I brought up a > > "STD_CONFIG" config symbol, which could be disabled to turn off all > > these additional "select"s. > > I apparently haven't explained myself enough, because what you keep on > harping on is not something I consider acceptable. > > STD_CONFIG is pointless. It's pointless because the solution to what > you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz > file at all. Linus, I think somehow you and Russell are talking past each other. I must admit I don't exactly understand what your suggestion is all about. But I however think that Russell's suggestion makes tons of sense. Care to elaborate on what you dislike about it? What is this Kconfig.xyz you're talking about? How different is it from, say, arch/arm/mach-pxa/Kconfig? If you look into that file, you'll find a bunch of select's which are fundamentally needed for the given targets to boot. This file could be augmented with more conditional select's � la STD_CONFIG as Russell is advocating to actually provide defaults for the drivers that those targets should have by default. Nicolas > So when I suggest special Kconfig files, they are meant to just generate > the templates - ie they'd _generate_ what is currently the defconfig > files. You wouldn't _have_ to use them at all. Sure. a standard "make config" would still produce that .defconfig as usual. Only that you'd have to turn STD_CONFIG off to be offered the choice of enabling/disabling those drivers which are enabled by default otherwise, just like the "make foo_defconfig" is doing now. Nicolas |