On Tuesday 10 July 2012, Ingo Molnar wrote: > So are you really convinced that the colorful ARM SoC world is > not going to go 64-bit and will all unify behind a platform, and > that we can actually force this process by not accepting > non-generic patches? Is such a platform design being enforced by > ARM, like Intel does it on the x86 side?
We can almost build a kernel for all modern platforms on 32 bit, and we know what pieces are missing. There is no technical reason why we don't have a single kernel for all ARMv6 and ARMv7 platforms already, it's just a shitload of work to get there starting out with the existing platform code. Of course we will have a lot of embedded 64 bit ARM SoCs, but I'm convinced that we can deal with those. Rejecting crappy code is easy as long as you can point to what they got wrong specifically. There will also be out of tree platforms that might not follow the same standards, but who cares about those? > > * Unlike on 32 bit, the different platforms cannot be > > compile-time exclusive. A platform port that cannot be enabled > > without breaking another platform is not getting merged. > > > > * I do not expect board-specific kernel patches, at least no > > more than we have them on x86 with the occasional hack to work > > around a broken machine. > > If 64-bit hardware is made on existing SoC designs, which looks > rather likely, then we are not in a position to reject kernel > support for them. > > Saying 'no' is very rarely a valid option for hardware ugliness. > We are encouraged to say 'no' for software details that is > actionable by the author of the patches, but hardware ugliness > is rarely actionable on that level and we are not holding our > users hostage in general just to make a point about ugliness. We're doing it already for 32 bit. All new 32 bit platforms have to follow the strictest rules for doing things the right way. With 64 bit, we can raise the entry barrier even higher. A much bigger problem than getting new contributions to be done right is fixing the existing ones without regressing on hardware support. > > * The differences between SoCs will be confined to device > > drivers to a much larger degree than they are on 32 bit, > > partly because the SoC companies are trying to be fit into the > > single-kernel model, and partly because we have added the > > infrastructure to allow it. > > There's 600 KLOC of code in arch/arm/, that's 3 times larger > than arch/x86/. Most of it is not in any fashion related to the > bitness of the CPU, it's platform IO code that is in principle > bitness agnostic. > > I have a really hard time imagining that all 64-bit ARM hardware > will be supported from drivers/: IRQ controllers, timer drivers, > all the ugly SoC details. > > Do you really think that all of the 32-bit ARM code should > essentially be thrown away when going to 64-bit ARM, that > patches can only touch arch/arm64/ + drivers/ or the highway? Yes. If you're curious, please have a look at arch/arm/mach-spear13xx/. this is the latest platform that we have added. It's fully functional (except PCI, which I hope will be added in drivers/pci/bus, which is another story), A significant portion of that platform deals with SMP support, which is being standardized for AArch64, so there will be only one implementation. Another big portion is DMA-engine support, which is moving out of arch/arm as soon as we have a proper DT binding. Finally there are some boilerplate header files that are going away too. Once we're done with this, we will basically need zero code in arch/*/ to support a new platform, and that is very easy to share between two distinct arch/* directories ;-) > The moment someone adds 64-bit CPU support to arch/arm/ and it's > merged we'll have an interesting situation on hand: support for > the same CPU in two different architectures in the kernel tree. What if they add 64-bit ARM support to arch/x86? AFAIK some of the machines are going to be basically PCs, including legacy I/O, ACPI and UEFI, so they are much closer to that than they are to anything in arch/arm. The instruction set of course is different, but you already said that this doesn't matter. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/