On Wed, Mar 30, 2011 at 07:31:59PM -0400, Nicolas Pitre wrote: > Sure, but important noise nevertheless. As long as the noise is > confined to a limited set of .c files I'm happy. OTOH I have very > little hope for a separate project that would only deal with that noise. > That will simply never fly, even less so as an Open Source project. It's also an excuse for people to make it a closed source project, and so you end up with platforms with a closed source binary blob passed into the kernel, which has hacky patches to fixup the binary blob parser to make it all work. We already see this with the damn simple memory layout stuff we already (try) to require of boot loaders. > Still... there are on-going efforts to consolidate things amongst all > the ARM vendors. The ARM architecture is standardizing more and more > stuff in the whole stack in every revision. But they won't standardize > everything otherwise they'll kill that competing ecosystem. Let's not kid ourselves over that effort: because there is already soo much code in mainline, the efforts to consolidate things can in itself create _big_ patches which will inflate the %age change under arch/arm. > > Now, some of it is quite understandable - ie real drivers for real > > hardware. But a _lot_ of it seems to be just descriptor tables, and > > I'm getting the very strong feeling that ARM people aren't even > > _trying_ to make it sane, and trying to standardize things, or trying > > to aim for the whole notion of "one kernel image, with much more hw > > description done elsewhere". > > That work is happening. It is not ready. I'm not against it but I > remain sceptical. I still think that a self contained kernel is more > maintainable. Let's not forget that in the future, the hardware should improve. There's efforts to standardise some of the peripherals, such as interrupt controllers and timers. The first attempt at architecting an interrupt controller for ARM has actually caused *more* complexity, as the architected interrupt (GIC) controller contained no power management. That has caused SoC vendors to bolt a second power management interrupt controller alongside the GIC which needs to be kept in sync. So... the result was yet more code which doesn't sit at all well with data descriptions of systems. > Still, because ARM is just a CPU architecture, those SOC vendors will > always have something new to differenciate themselves from the other SOC > vendors. And that cannot be described in a table alone. The power > management hardware from TI will still require separate _executable_ > code from the Freescale one, or the Samsung one, or the Nvidia one, or > the Qualcomm one, or the Marvell one, yada yada. And I really don't > want to see that code turned into some vendor provided buggy ACPI > bytecode or similar. To get rid of all the platform related stuff, I think you'd need some kind of bytecode to deal with some of the procedural stuff with various platforms. Without bytecode, the only other way is to keep the stuff as C functions in the kernel and find some way of binding them to drivers through DT, which means we're still going to have platform specific C files littering the kernel. While I can see DT solving the "declare this data structure" problem, I believe that's only part of the issue. This is exactly why when DT was proposed as a miracle cure-all for ARM, I wanted to see DT on a real ARM platform rather than just ARM Ltd's simple and similar development boards. Certainly, though, DT for ARM is progressing. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
