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: Russell King on 3 Jun 2010 14:50 On Thu, Jun 03, 2010 at 11:20:30AM -0700, Daniel Walker wrote: > I don't see how we can do without defconfigs altogether tho. I mean , if > you want to run a Beagle board or a Nexus one we can't just give the > users a slim ARM config and let them troll through 1000's of drivers > trying to find just those ones that work on their given board. Well, Linus does have a point - I can't start a new with Kconfig and generate a working defconfig first time mainly because of the thounds of options there. What I can do is get the ARM side of the configuration right, since for the majority of cases the only thing that needs doing is selecting the platform class and the board itself. The problem comes with driver configuration, where you have to go through lots of menus to find all the drivers for the platform/SoC. That's the tedious bit, and more often than not it takes several attempts to get everything that's necessary. -- 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: Linus Torvalds on 3 Jun 2010 15:00 On Thu, 3 Jun 2010, Russell King wrote: > > The problem comes with driver configuration, where you have to go > through lots of menus to find all the drivers for the platform/SoC. > That's the tedious bit, and more often than not it takes several > attempts to get everything that's necessary. It's often tedious for other cases too ("I just want to enable a particular driver, what do I need to do so?"), and I do agree with Daniel that the SAT solver approach sounds interesting as a way to solve some of the complexities. At the same time, "SAT solver" does scream "over-engineering failure" to me. We've had horribly bad experiences with over-engineering in that space before. Yes, I know about MiniSAT and that these things can be done without necessarily huge amounts of complex code, but these things tend to grow to huge monsters. Who knows. 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 15:00 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". 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. -- 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: Linus Torvalds on 3 Jun 2010 15:10 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. 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: Paul Mundt on 3 Jun 2010 15:30
On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote: > On Thu, 3 Jun 2010, Daniel Walker wrote: > > I don't see how we can do without defconfigs altogether tho. I mean , if > > you want to run a Beagle board or a Nexus one we can't just give the > > users a slim ARM config and let them troll through 1000's of drivers > > trying to find just those ones that work on their given board. > > Well, you also don't need the full defconfig's with the kernel. > That's true. We already have things like KCONFIG_ALLCONFIG for these purposes, and that's primarily what I use for buildig bootable randconfigs for specific board/CPU combinations on SH. -- 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/ |