Linux Patches: Reward Cooperation, Punish Selfishness

In "ARM is a promising platform that needs to learn from the PC", a general solution is proposed to the ongoing problem caused by nothing more than the ARM architecture being by far and above the most ubiquitous silicon-based computing engine on the planet. The solution is, at its core, very simple: penalise selfishness, and reward cooperation. This is the basic fundamental principle behind Free Software, and the Linux Kernel is rapidly moving towards a dumping-ground for selfish SoC manufacturers, selfish ODMs and pathologically selfish Corporations in general to expect the Free Software Community to clean up their mess.

This fundamental principle - to reward cooperation (by prioritising patches where collaboration is evident) and to penalise selfishness (by rejecting or de-prioritising patches which are for one device, one CPU, for one manufacturer and conform to no common standards) - has accidentally been in effect since the very first Linux Kernel, across virtually the entire x86 platform. but only by sheer luck.

For example: the PC "BIOS" is responsible for normalising all PCs, Laptops, Servers and Embedded x86 systems. Thus, behind the "BIOS" is enforced and reluctant cooperation, with a history of lawsuits and reverse-engineering behind the second and subsequent compatible BIOSes. The Northbridge-Southbridge architecture is responsible for normalising system architectures. The use of the ISA bus, which spawned the IDE Drive as well as, decades later, the PCI bus range, meant that a vast range of peripherals are covered. USB is the same. VGA is, again, the same. At every level of the x86 architecture, there is evidence of cooperation through standards (or forced through de-facto standards), and the end result is massively less work required to be carried out to maintain the x86 Linux Kernel.

This is the "Lesson of the PC" that the ARM community has not learned.

Therefore, the proposed rule that is advocated for Linus Torvalds to adopt towards patches is this:

• Does the patch show any evidence of collaboration, unencumbered open standards compliance, cooperation or sharing of resources, of any kind?
• If not, does the git commit message show any evidence (text or links)?
• If answer "no" and "no" to the above, reject the patch.

Within this profoundly simple proposed rule, there is a great deal of flexibility, which it may help to illustrate with a FAQ. It is assumed in each and every case that existing code-quality rules apply, and that the patch follows and meets, without fail, every single other well-established rule which is normally applied to Linux Kernel Patches.

• I am a SoC manufacturer, we have created a custom CPU, we have placed it into one and only one hardware design, and we are restricting the SoC to sole and exclusive use in that hardware. please accept our one-SoC, one-design linux kernel patches"
  Answer: not a cat in hell's chance.
• Ah sorry. I am a SoC manufacturer, we have created a custom CPU, we have placed it into one and only one hardware design, but we have released the SoC's VLSI designs under an OSI-approved Free Software License on OpenCores.org. We still only have and sell one proprietary platform, but other people may fork or manufacture or synthesise in an FPGA our VLSI design and make their own hardware platform that way. please accept our one-SoC, one-design linux kernel patches"
  Answer: if you provide a link to the VLSI design, port libc6 to the CPU, and respect the GPL on the gcc compiler and standard library toolchain, absolutely!
• We are a reverse-engineering team who have found a device which is an entirely embedded SoC, it is one-of-a-kind, but it is so incredibly common that we have reverse-engineered a Linux Kernel onto it, made an open web site and now we have a huge community based around it (link), doing all sorts of weird and wonderful things. Even though it's totally proprietary.
  Answer: yes, absolutely - fantastic. We'd like to see more refactoring but if it's truly utterly unique then obviously that can't happen, but as a rule yes, your patches clearly qualify because of the large community based around it.
  References: XDA-Developers and Handhelds.org, where significant reverse-engineering takes place.
• I am a new x86 "clone" manufacturer (e.g. RDC). Our CPU is interoperable entirely with the old 586s. Please accept our patch to add this new CPU
  Answer: if the CPU is entirely interoperable with 586s, it doesn't need to be added as a separate arch, does it?
• Ah sorry: we meant that we have an Engineering Board, which has PCI-e built-in but otherwise it internally has Northbridge-Southbridge Architecture - just on one single IC. Please accept our patch to add this new CPU, and our Engineering Board Reference Platform as a new MACHINE
  Answer: if you can provide evidence that you have multiple ODMs cooperating and collaborating to create systems based on this Reference Platform: yyyep you're in.
• We are a new x86 "clone" manufacturer. We have made it interoperable as best we can with its closest competitor, and have performed major positive refactoring of the x86 code. Please accept our patches.
  Answer: yes, fantastic. looking forward to more positive refactoring which benefits more than just your own CPU.
• I am a factory with x86 systems, we have created a GPIO-based bit-banging driver for our special bit of proprietary hardware with an x86 CPU, which only works on our special custom-made x86 boards manufactured solely in our factory. Please accept our bit-banging patch.
  Answer: not a snowball in hell's chance.
• Oh, sorry. We actually have quite a lot of customers (several million), actually we are submitting the patch from one of our customers because its code quality was better than our own, and you can see evidence here (link), here (link) and here (link) that we are acting under pressure from Free Software Enthusiasts. Please accept our bit-banging patch.
  Answer: yeah all right, but only because there is evidence of collaboration in the form of multiple Free Software Developers. Your hardware design is utterly shit. Do Sort It Out, There's Good Chaps.
• We have Sorted Out our new hardware: it's still proprietary motherboards, still using x86, but we now use the USB bus, and we now sell the peripheral as a separate device. Please accept our patch.
  Answer: yes sirree, of course we will. Evidence of future collaboration is demonstrated by the fact that, as your peripheral is now for sale as a separate device, it would, naturally, work on absolutely any architecture, not just your own proprietary x86-based motherboards. Hurrah.
• We are a new ARM SoC vendor. We...
  Answer: yep, your core system code is automatically in.
• Oh, thank you! ok, we have a completely different GPIO and IRQ layout from absolutely everybody else. It's specialll. It's got multiplexing and everything. It saves us on manufacturing, makes us competitive. no really. It's really popular because it's so low-cost, we have hundreds of ODMs using it already!
  Answer: oh, christ. not another one. yep: ok, well, given that you have so many ODMs creating platforms, hang on... but they're all GPL violating! Nope. go away. get that sorted out, and provide evidence that those ODMs are actually collaborating, or that collaboration is occurring somewhere.
• We're so sorry! we've adjusted our NDAs and brow-beaten some of our ODMs into GPL Compliance: you can now see evidence of collaboration between factories and ODMs, here (link), here (link) and here (link)
  Answer: good one. yep, your yet-another-GPIO-layout and multiplexing stuff is in... but sort it out!
• Thank you. now, we licensed some USB-2 and 10/100 Ethernet Macro Cells from {Insert Fab Design House Here}, they're very common, hence we got them dirt-cheap, and we've had to write our own Device Drivers. Please accept our patches to add support for USB-2 and 10/100 Ethernet, just because they're built-in to our CPU and it would be inconvenient to us if they weren't in the Linux Kernel.
  Answer: abso-f*****g-lutely not. These Macro Cells are known to be supported across dozens of CPUs. you can damn well add them as a configureable "devicetree", just like every other SoC Manufacturer using the exact same Macro Cells has done.
• Ok, we will do that. Now, we also are the world's first adopters of the new spangly USB-4 and SATA-IIII Macro Cells! We're so proud of it, we even wrote the Linux Device Drivers for the world's only USB-4 keyboard and the world's only SATA-IIII SSD drive. Please accept our patches.
  Answer: well, as you are the world's first adopters, there is no evidence of collaboration. Therefore, sorry, you will have to wait until another SoC manufacturer adopts the same Interfaces, or you will have to wait until there are significantly more devices (and Linux Drivers) from more third party manufacturers that are interoperable with these Buses.
• We are a factory who have created a great new tablet! It is one of a kind, it supports lots of existing devices, uses existing Linux Kernel Drivers: all we need is to add the platform-specific files, and we will be in main-line Linux Kernel, yess!
  Answer: nooo. You have only one tablet. your 20 platform-specific files are just noise. sorry. go away.
  References: Board files are just noise"
• Okay. well, we now have threeee great new tablets! They are all one-of-a-kind!
  Answer: why did you even bother to send in the patches?
  References: Board files are just noise"
• Whoops, sorry. we threw those designs away, and came up with a consolidated architecture where all the tablets can use the exact same platform-specific files: the detection is a kernel boot parameter.
  Answer: now you're talking turkey. welcome to the club. References: Long-term solution: one binary kernel "just works": hardware description is "elsewhere".
• We are a factory / ODM who have created a modular architecture based around {SO-DIMM / custom-module / other standard} where the main CPU is on the card, and you plug this CPU card into a motherboard with pretty much any peripherals that our customers want. We only have one CPU card at the moment but we have others planned, and we have designed the Kernel Patches to take into account future CPU modules, in advance.
  Answer: If you have full documentation of the standard, as part of the patch, or a link to it, and can show evidence that although it's a de-facto standard it's otherwise unencumbered, fully and comprehensively documented and completely open, such that other design houses can create modules conforming to this architecture you have designed, then yes, patches around your shiny modular architecture are in. Otherwise, you will have to wait until you have evidence of multiple modules or multiple motherboards.
• We have created a patch which normalises GPIO access across a massive range of CPUs, but, obviously, it affects a significant number of platforms, even though it reduces the amount of code required by 80%. Please accept the patch?
  Answer: about damn time.
• We are a SoC Vendor, we have created a one-off platform which is now entirely under a Hardware Open Design License, but it is one-of-a-kind, unique, etc. etc. Please accept our patches
  Answer: of course! anyone can take that hardware CAD/CAM files and create a new platform. great evidence of collaboration: love the fact that the BSP doesn't require an NDA or conflict with the GPL or anything. good luck!
• We are a University, we have created a one-off platform which is now entirely under a Hardware Open Design License, but it is one-of-a-kind, unique, etc. etc. Please accept our patches
  Answer: of course!
• We are a proprietary company: we have taken one of the above "Open Hardware" platforms, and have created our own board. All we have done is added a WIFI module, and we have a new MACH_TYPE. We've done our best to use devicetree to share as much code between the common hardware types, but obviously our WIFI module is unique. We are not however going to release the CAD/CAM designs because they're Apache2 Licensed, and we don't have to. Please accept our patches
  Answer: well.... yeah ok, but just this once. If you released the CAD/CAM drawings, it'd be yes immediately. We will have to keep an eye on this situation, to see who else adds random peripherals to otherwise very similar hardware designs.
• We are an ARM-based SoC vendor (or we are Linaro), and we have created some patches which put the AMBA Bus into line with PCI, USB and all other generic buses, and we have done it in such a way that many other SoC vendors can add support for this AMBA bus kernel support as well. It's wonderful. please accept our patches.
  Answer: excellent. at least you're trying. probably won't succeed in making a large dent in the code-base, but it might help long-term.
  References: AMBA Bus discoverable hardware that sadly is not as ubiquitous as it should be: many SoC vendors simply have not bothered to add the required "magic" in place.

Overall, it can be seen that many of these examples appear to be common sense. And, for every single one of the above to which there is an answer "no", close examination shows that if the CPU was an x86 architecture, in may cases there would be absolutely no problem. It is only in the context of massive diversity - devoid of common standards and cooperation of any kind at quite literally every single level, from the CPU's core architecture, to its peripherals right the way to the actual PCB - that the maintenance of ARM-related Linux Kernel Source Code becomes a complete nightmare.

Or, more specifically, the Linux Kernel Source Code presently and accurately reflects the state of play: total selfishness of all Corporations involved in making money out of the ARM architecture, at the expense of the Free Software Community.

The proposed rule therefore puts collaboration and cooperation directly at the heart of the Linux Kernel Free Software Development, where it belongs.

Comments and FAQ examples to: lkcl@lkcl.net