ARM MSM updates for 2.6.35-rc1
in [Kernel]
|
Prev: [PATCH] checkkconfigsymbols.sh: Kconfig symbols sometimes have lowercase letters
Next: failed command FLUSH CACHE EXT (was: Re: via 8237 sata errors)
From: Kevin Hilman on 2 Jun 2010 19:30 Linus Torvalds <torvalds(a)linux-foundation.org> writes: > On Wed, 2 Jun 2010, Daniel Walker wrote: >> >> Don't forget about this one! Or was something wrong with it? > > I got a bit frustrated with ten different ARM pulls per day at one point. > > There's something wrong with ARM development. The amount of pure noise in > the patches is incredibly annoying. Right now, ARM is already (despite me > not reacting to some of the flood) 55% of all arch/ changes since 2.6.34, > and it's all pointless churn in > > arch/arm/configs/ > arch/arm/mach-xyz > arch/arm/plat-blah > > and at a certain point in the merge window I simply could not find it in > me to care about it any more. > > Do you guys at all talk about this problem? Have any of the ARM people > bothered to look at the arch/arm diffs and see how mind-deadening they > are? I try to look through these kinds of things when I pull, but after a > million lines of pure noise, it gets old pretty quickly. > > Somehow, I can't believe that you need thousands of lines for each random > arch/arm/mach-xyz (yeah, some very few of them are smaller). As one of the sub-arch maintainers (arch/arm/mach-davinci), I can attempt to answer for some of the churn. There indeed has been lots of change in mach-davinci, but I wouldn't consider it noise. In that one mach directory, I support ~10 SoCs in the same family and for each SoC there is at least one board supported. I'm also a core developer for mach-omap*, and the number of SoCs/boards supported there is equally large. Each time we add support for a new SoC in the family some changes are needed to generalize existing code to work on the existing SoCs as well as the new ones. This generalizing is actually reducing the size of the diff compared to what it would be if it were added using copy-paste, but I understand why it might look like churn. I certainly understand why this would be mind-numbing to anyone who doesn't care about davinci, or ARM-based devices. Indeed, even other ARM sub-arches developers don't need to care about most of what is in my mach dir and would consider it mind-numbing as well. The fact is that ARM-based devices multiply like rabbits, and there is a huge amount of diversity between the various derivatives. Also, support most of these devices has lived out of tree for a long time. Now that we have a relatively direct path which doesn't require any single person to have to understand all the mind-numbing details of all of these ARM-based platforms, it has allowed us to significantly improve the support for these devices upstream. Anything that is common to all devices still goes through RMK. Kevin -- 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 2 Jun 2010 21:30 On Wed, 2 Jun 2010, Kevin Hilman wrote: > > There indeed has been lots of change in mach-davinci, but I wouldn't > consider it noise. In that one mach directory, I support ~10 SoCs in > the same family and for each SoC there is at least one board > supported. I'm also a core developer for mach-omap*, and the number > of SoCs/boards supported there is equally large. The problem with this is that it's just not maintainable to keep on adding random stuff, especially since I doubt any of it ever gets aged away either. arch/arm as-is is already about 800k lines. Compare that to arch/x86, which is less than a third of that. Now, what is the difference? - x86 has its drivers elsewhere, and they are _discoverable_ and not hardcoded to some platform. They have often also been useful (to say the least) to other architecture platforms. That's not always true for all of them (we do have drivers/platform/x86, but at least that's maintained separately and is nowhere near the mess that is ARM) - in contrast, ARM seems to be a mess. I realize it's largely because the hardware companies are so f*cked up, but guys, we need to have some handle on it too. I was willing to take the direct merges, and I still am, but I'm willing to do it only if I have a feeling that things are under control. And I'm not getting that feeling. - TWO HUNDRED THOUSAND lines of arch/arm is just pure garbage, namely the defconfig files. Quite frankly, anybody who calls that anything but pure "noise" is just misguided and being stupid. So yes, I do consider a lot of it "noise". When there's two hundred thousand lines of garbage, and it keeps growing without bounds, something needs to be done. Now, I'm actually considering just getting rid of all the 'defconfig' files entirely. The x86 model is sane (there's two of them, nobody likely uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have turned the whole concept into a disgusting mess. But while POWERPC has abused that thing too, in _other_ respects it has been much less egregious. So I can largely fix the defconfig mess on my own (by just using a simple oneliner shell script to deletes them all) but that really only fixes one particularly annoying symptom - not the underlying issue. We do need somebody to maintain the arm platform mess, and actually tries to get some infrastructure or something in place so that it doesn't explode. > The fact is that ARM-based devices multiply like rabbits, and there is > a huge amount of diversity between the various derivatives. Also, > support most of these devices has lived out of tree for a long time. > Now that we have a relatively direct path which doesn't require any > single person to have to understand all the mind-numbing details of > all of these ARM-based platforms, it has allowed us to significantly > improve the support for these devices upstream. Anything that is > common to all devices still goes through RMK. The thing is, I bet there is way more commonality still to be taken advantage of. And even if there isn't, we need somebody who cares, and doesn't just mindlessly aggregate all the crud. Somebody with the taste to say "ok, that's just too effin ugly, you need to fix things up" occasionally. 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: Michael Ellerman on 2 Jun 2010 23:50 On Wed, 2010-06-02 at 18:20 -0700, Linus Torvalds wrote: > > Now, I'm actually considering just getting rid of all the 'defconfig' > files entirely. The x86 model is sane (there's two of them, nobody likely > uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have > turned the whole concept into a disgusting mess. I agree that the defconfig mechanism is broken (ie. carrying the full text in tree), but the concept is sane IMHO. What'd be nice is if the defconfig could just be a delta against a base config for the architecture - that would make most of them reasonably small, just turning on/off a few options. You can sort of do that today, by just storing a delta, but oldconfig will silently turn off things you have enabled if prereqs change, so that doesn't really work I think. cheers
From: Linus Torvalds on 3 Jun 2010 00:40 On Thu, 3 Jun 2010, Michael Ellerman wrote: > > You can sort of do that today, by just storing a delta, but oldconfig > will silently turn off things you have enabled if prereqs change, so > that doesn't really work I think. I think you can do it today with various hacks. Up to and including basically doing something that just selects the options you want. IOW, you could likely have a human-written Kconfig.<platform> file that just does define_bool MYPLATFORM y select .. everything I need .. include Kconfig.main or a number of other tricks. Ingo and the x86 folks (who I really think have done a very good job, and there really aren't any crazy defconfig files there) have this "make randconfig" together with scripted requirements so that you can actually _boot_ the random config, just because the requirements make sure that the things needed for booting on the test setup are selected. I forget exactly what the build setup there is (Ingo described it to me long time ago, but since I don't even want to have a build farm in my home, I didn't care much). But we certainly _can_ do a better job than the 'defconfig' thing that was really never meant for the kind of use it sees in ARM/POWERPC/SH/MIPS, and that really isn't appropriate for any manual editing (so people just run "make oldconfig" with tweaking or something, and then use the newly generated file). And I suspect that it really is best to just remove the existing defconfig files. People can see them in the history to pick up what the heck they did, but no way will any sane model ever look even _remotely_ like them, so they really aren't a useful basis for going forward. But don't worry. It didn't happen this merge window, obviously. 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: Ben Dooks on 3 Jun 2010 00:50
On Wed, Jun 02, 2010 at 06:20:09PM -0700, Linus Torvalds wrote: > > am, but I'm willing to do it only if I have a feeling that things are > under control. And I'm not getting that feeling. > > - TWO HUNDRED THOUSAND lines of arch/arm is just pure garbage, namely the > defconfig files. Quite frankly, anybody who calls that anything but > pure "noise" is just misguided and being stupid. > > So yes, I do consider a lot of it "noise". When there's two hundred > thousand lines of garbage, and it keeps growing without bounds, something > needs to be done. > > Now, I'm actually considering just getting rid of all the 'defconfig' > files entirely. The x86 model is sane (there's two of them, nobody likely > uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have > turned the whole concept into a disgusting mess. > > But while POWERPC has abused that thing too, in _other_ respects it has > been much less egregious. unfortunately there are so many different variants of the ARM architecture that these defconfigs spring up to ensure that a base compile for each one of them is performed. We run an autobuild which runs through all these defconfigs and produces a report of what happened to allow tracking of build regressions at the moment. > So I can largely fix the defconfig mess on my own (by just using a simple > oneliner shell script to deletes them all) but that really only fixes one > particularly annoying symptom - not the underlying issue. We do need > somebody to maintain the arm platform mess, and actually tries to get some > infrastructure or something in place so that it doesn't explode. Someone should defiently cull the older defconfigs for sepcific machines, many of which probably don't get built for mainline. ~ > > The fact is that ARM-based devices multiply like rabbits, and there is > > a huge amount of diversity between the various derivatives. Also, > > support most of these devices has lived out of tree for a long time. > > Now that we have a relatively direct path which doesn't require any > > single person to have to understand all the mind-numbing details of > > all of these ARM-based platforms, it has allowed us to significantly > > improve the support for these devices upstream. Anything that is > > common to all devices still goes through RMK. > > The thing is, I bet there is way more commonality still to be taken > advantage of. And even if there isn't, we need somebody who cares, and > doesn't just mindlessly aggregate all the crud. Somebody with the taste to > say "ok, that's just too effin ugly, you need to fix things up" > occasionally. yes, there is that problem, and many of the big company players have yet to really see the necessity in this... It has taken a while now to convince the necessary people at Samsung that simply copying and modifying existing driver/support is simply not going to fly. -- Ben (ben(a)fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- 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/ |