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: Felipe Contreras on 5 Jun 2010 09:50 On Thu, Jun 3, 2010 at 11:31 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Thu, 3 Jun 2010, Linus Torvalds wrote: >> >> 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. > > To make this _really_ concrete, let me actually give you an example (but > broken and pointless) example Kconfig file, in order to _avoid_ having a > def_config file. > > I do it by generating it. Let's say that I want a x86 configuration that > has USB enabled. I can basically _ask_ the Kconfig machinery to generate > that with something like this: > > - create a "Mykconfig" file: > > config MYCONFIG > bool > default y > select USB > > source arch/x86/Kconfig > > and then I just do > > KBUILD_KCONFIG=Mykconfig make allnoconfig > > and look what appears in the .config file. In fact, do this: > > make allnoconfig > cp .config no-config > KBUILD_KCONFIG=Mykconfig make allnoconfig > cp .config my-config > diff -u no-config my-config > > to see the point of it all. > > Now, the above is a _trivial_ one. And it's actually broken, because I > should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). And that's precisely the problem that his approach doesn't solve: dependencies. --- config MYCONFIG bool default y select MACH_OMAP3_BEAGLE source arch/arm/Kconfig --- Is the same as: --- source arch/arm/Kconfig --- With the SAT resolver it would be possible to have a .satconfig: CONFIG_MACH_OMAP3_BEAGLE=y And let the resolver figure everything out back from there. -- Felipe Contreras -- 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: Felipe Contreras on 5 Jun 2010 10:20 On Fri, Jun 4, 2010 at 12:17 AM, Tony Lindgren <tony(a)atomide.com> wrote: > * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 23:30]: >> >> and now you'd be able to basically generate a OMAP3EVM .config file by >> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >> only have to select the parts that are specific for the EVM platform, >> because the generic OMAP3 support would be picked by the Kconfig.omap3 >> file, which in turn would not have to worry about the generic ARM parts >> etc. >> >> See? > > Sounds like a good improvment to me. How about instead of using full defconfigs, we use minimal ones and let the rest be determined with defaults. For example, omap3_beagle.baseconfig would have something like: CONFIG_MACH_OMAP3_BEAGLE=y CONFIG_ARCH_OMAP=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP3430=y CONFIG_AEABI=y CONFIG_EMBEDDED=y CONFIG_ARCH_OMAP_OTG=y CONFIG_OMAP_MUX=n CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_DM_TIMER=y CONFIG_INPUT_MOUSE=n You copy that to the .config, and then do: echo "" | make ARCH=arm oldconfig The result would be exactly the same as we have now. With the SAT resolver I think it should be possible to automatically simply the current defconfigs. (CC'ing Vegard for comments) I'm attaching a simplified base config, that I used to test this, and the result is an exact match of the current omap3_beagle_defconfig. -- Felipe Contreras
From: Linus Torvalds on 5 Jun 2010 10:50 On Sat, 5 Jun 2010, Felipe Contreras wrote: > > How about instead of using full defconfigs, we use minimal ones and > let the rest be determined with defaults. I wouldn't mind that either, but there needs to be some way to check that they _are_ minimal. Which is more complicated than even SAT, afaik. So the reason I don't like the "minimal defconfig" notion is that a "regular defconfig" will work equally well, and lazy people will thus not bother to make it minimal (because it's work) and instead just pick the full config output. And we're all lazy. So gearing the process towards something that makes it easy for lazy cases to do the wrong thing is a bad thing. We also don't have any way to "source" these config files from each other, so there's no way from within such a config file to say "use the basic omap3 defaults an then just add this on top". You can do it by concatenating several such files manually from the Makefile or whatever script, of course, but then you end up with the files themselves not actually describing what they do. That's why I suggested the Kconfig format instead. It's the exact same idea, but it's a "before pre-processing" format that already supports including other files. 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: Felipe Contreras on 5 Jun 2010 12:40 On Sat, Jun 5, 2010 at 5:39 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Sat, 5 Jun 2010, Felipe Contreras wrote: >> >> How about instead of using full defconfigs, we use minimal ones and >> let the rest be determined with defaults. > > I wouldn't mind that either, but there needs to be some way to check that > they _are_ minimal. Which is more complicated than even SAT, afaik. I don't think so. The SAT should be able to come up with a minimal config for 'CONFIG_MACH_OMAP3_BEAGLE=y', and then a minimal config for whatever is in omap3_beagle_defconfig. The diff is either unnecessary, or the Kconfig files are missing some 'default y if whatever'. You fix the Kconfig files, and then use the resulting minimal config. > So the reason I don't like the "minimal defconfig" notion is that a > "regular defconfig" will work equally well, and lazy people will thus not > bother to make it minimal (because it's work) and instead just pick the > full config output. > > And we're all lazy. So gearing the process towards something that makes it > easy for lazy cases to do the wrong thing is a bad thing. Yes, that's why I lean toward the solution that creates an ideal config with the minimal effort: SAT with a single CONFIG_MACH_OMAP3_BEAGLE=y. Then you don't need defconfigs at all. > We also don't have any way to "source" these config files from each other, > so there's no way from within such a config file to say "use the basic > omap3 defaults an then just add this on top". You can do it by > concatenating several such files manually from the Makefile or whatever > script, of course, but then you end up with the files themselves not > actually describing what they do. I don't really see the big need for hierarchical configs. When you do 'make ARCH=arm' you are already including all the arm stuff, so there's no need for an ARM base config. Then you would need some platform stuff like OMAP3, but if you do CONFIG_ARCH_OMAP3=y, and there are proper 'default y if ARCH_OMAP3' in the Kconfigs, you don't need any base config either. The rest of the stuff is truly specific to the boards. If there's a need to include other configs, I'm sure we can come with markups to include them and have a parser script that generates the ..config. > That's why I suggested the Kconfig format instead. It's the exact same > idea, but it's a "before pre-processing" format that already supports > including other files. Yes, although I don't like the format (it looks clearly designed for something else), it's another possibility. However, I don't think "allnoconfig" makes sense because that would ignore the default hints already present in Kconfig files. -- Felipe Contreras -- 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: david on 5 Jun 2010 23:40
On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 11:18:05AM -0700, Linus Torvalds wrote: >> >> >> On Thu, 3 Jun 2010, Russell King wrote: >>> >>> Umm. I don't think you've actually looked at the Kconfig files if you're >>> writing this, because that's precisely what we already do. >> >> .. but if you do this _right_, then the defconfig files would be >> unnecessary. >> >> That's my point. If you are right, then I can remove the defconfig files >> entirely. Are you ready for that? > > Absolutely no way are we ready for that. > >> And if you aren't ready for that, then what was the point of your email? > > Linus, don't make this personal. > > The problem is NOT "what options which are found under the arch/arm tree > do I need". > > The problem is "what options throughout the rest of the kernel do I need > to result in a usable kernel". What do you define as useable? at two extremes: do you mean a kernel that fully supports the board and all it's features? do you mean a kernel that will compile and boot, but may not be able to talk to the outside world as it doesn't know about any I/O that the chip may have. I don't think that defconfig can work for the first case (every single system would hae it's own defconfig, which just doesn't scale) and I'm not sure the second is very useful (and it should be covered by the kconfig defaults) if you are looking for something in between, where do you draw the line? back when linux ran on x86 with IDE only, defconfig made a lot of sense, but that was because the hardware was very standardized, nowdays even in the x6 space there is enough variation that it's questionable how useful a defconfig is. What would be far better would be some tool that would take some hardware defintition (either autodetecting from a currenlty running system on x86, or from the device_tree stuff that's being worked on for other architectures) and create a kernel config from that that would fully support the hardware detected. David Lang > 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. > > For instance, if I have platform A, I know it has an RTC. How do I know > which of the 37 RTC drivers the kernel configuration presents me with to > select? Am I really expected to open up the platform and read the > device numbers off all the chips (some of which being surface mount are > abbreviated) and work out that it's a TWL4030 RTC that I should be using? > > That's just one instance - and there's probably many more just like that. > Just look at "multifunction drivers" for another case in point. How the > hell do I know what multifunction driver is appropriate for a platform? > > Ditto "Power supply support". > > The list goes endlessly on. All those things I've mentioned are all > _outside_ of arch/arm. That's where the _real_ problem is. Solve that > problem so that it's easier for people to configure the kernel, and then > we don't need the multitude defconfig files. > > That's the problem which the defconfigs are solving today. > > -- 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/ |