Welcome to LWN.net
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank youfor visiting LWN.net!
Free trial subscription Try LWN for free for 1 month: no payment or credit card required. Activate your trial subscription now and see why thousands of readers subscribe to LWN.net.
The news for processors and system-on-chip (SoC) products thesedays is all about 64-bit cores powering the latest computers andsmartphones, so it's easy to be misled into thinking that all 32-bittechnology is obsolete. That quickly leads to the idea of removing supportfor 32-bit hardware, which would clearly make life easier for kerneldevelopers in a number of ways.
At the same time, a majority of embedded systems shipped today do use 32-bitprocessors, so a valid question is if this will ever change, or if 32-bitwill continue to be the best choice for devices that do not requiresignificant resources.
To find an answer, it is worth taking a look at different types of systemssupported in Linux today, how they have evolved over time with theintroduction of 64-bit processors, why they remain popular, and whatchallenges these face today and in the future.
Linux was first written as a desktop system for IBM PC compatibles, and waseventually ported to almost every other desktop platform available in the1990s, including a lot of the early Unix workstations across allarchitectures.Over time, all of these were replaced with 64-bit machines or theydisappeared from the market, or in case of Unix workstations, both. Theearliest i386, Arm, MIPS, and PowerPC processors all got phased out overtime, but a lot of others still remain.
The table shows the 32-bit desktop platforms that proved popular enough tomake it into mainline Linux and stay there, supported mainly by loyalhobbyists:
PlatformArchitecturesEarliest supported machineLast supported 32-bit machineEnd of marketingReplaced by
IBM RS/6000 43P-240,
HP Visualize B180L
x86 Linux, 64-bit Unix
Mac II (1987)
x86-64, arm64 Mac
IBM compatible PC
PS/2 model 70 486
Intel Atom D270 Netbooks(2009)
StrongARM RiscPC J233
Netwinder “Frog” (1999)
NetWinder 3100 (2001)
Various, Android 8(2019)
Asus Chromebook Flip (2015)
Android tablets using Armv7 processors are the only platform from the listabove thatremains widely available in 2020, but the end of marketing is in sight here aswell. Tablets based on 64-bit Armv8 CPUs are not just more powerful butoften also cheaper. Mainline support for many 32-bit Android tablets isonly starting to get added to the kernel. (For those who are unfamiliarwith the taxonomy of Arm processor variants, thistable describes them all).
The Baikal T1 chip is a curiosity, as it only exists for the Russiandomestic market to avoid relying on chip imports. It too has an Armv8successor, but that is not yet widely deployed. Kernel support for theBaikal T1 was added in 2020.
Traditional embedded Linux
The use of Linux in embedded devices started in the late 1990s and, overtime, spread to around 30 architectures, largely replacingother embedded operating systems. A lot of these were custom architecturesmade by companies that build system-on-chip designs around their own CPUcores. Over time, licensable CPU IP cores took over, with MIPS, PowerPC,x86, and SuperH cores being popular until Arm started replacing them.
These are the most recent licensable 32-bit generations for each of themain processor families supported in Linux-5.10:
(Licensed from Arm)
AMCC PowerPC 460
Power ISA 2.03
IBM PowerPC 470
Power ISA 2.04
Power ISA 2.06
(Licensed from Arm)
MIPS Warrior P5600
Cadence Xtensa LX7
OpenCores mor1kx v5
ARCv3 (32/64 bit)
MIPS Warrior I7200
As the table shows, almost all of these cores have introduced 64-bitreplacements from their original designers, but most manufacturers keep on supportingthe 32-bit versions as well. Hitachi (now Renesas) and Freescale (now NXP) introduced64-bit core designs of their SuperH and PowerPC cores, but subsequentlyabandoned them in favor of licensed Arm Cortex-A cores.
The OpenRISC project is still active, but a lot of its contributors havemoved on to working on RISC-V designs. Cadence Tensilica has not announceda replacement for the Xtensa LX7 but is apparently focusing on its DSPcores.
Some CPU cores end up being used for a long time in new SoCs. For instance,the Arm9 CPU was originally created in 1998, with the Arm926EJ-S updatefrom 2001 still making it into the new Microchip SAM9X60 in 2019. Not onlythat, Microchip also still supports mainline Linux on its ancestor, the2003 vintage AT91RM9200, and promises to sell it as long as there isdemand.
The manufacturers' specifications for product longevity of a part cangive some indication of how long it will be used, but this is notalways the same as the time for which it will receive kernel upgrades. Manyembedded systems are shipped with an old kernel and never upgraded, othersmay be required to get periodic upgrades many years after the last one hasshipped.
These are some more examples of notable chips that are built on older coresor CPU architectures but will remain in production for several years tocome, usually side by side with more powerful and newer Armv7 or Armv8based parts.
RZ, R-Car series
NXP QorIQ P3041
Coldfire v4 (m68k)
Intel Quark SE C1000
The end-of-life date in this table usually refers to themanufacturer’s last guaranteed shipment date, often 10 or 15 yearsafter the introduction, but for popular chips like the BCM2835, kernelupdates may be needed long after the last chip has been sold. The m68k-basedColdfire MCF5441x is interesting because it represents the oldestarchitecture that Linux runs on, and it will still be sold until at least2025, which is 40 years after the introduction of its Sun-3 ancestor, theoldest machine with Linux support. At that point it will have outlivedalmost every other 32-bit architecture that was meant to replace it.
The more recent examples tend to be built as system-in-package processorsthat include 32 to 256 megabytes of DRAM. This helps further reduce boarddesign cost, which is the main reason to use any of these parts instead ofthe more common Armv7 alternatives in new designs.
Microcontrollers and DSPs
The line between an SoC and a microcontroller can be hard todraw. Typically a microcontroller is a highly integrated system that leavesout one or more of the essential parts of a modern SoC: a memory-managementunit (MMU), data cache, external DRAM memory, or sometimes anIEEE-754-compatible floating-point unit. Linux does not strictly requireany of those, but running without an MMU in particular limits theapplications that can be used on the system.
Digital signal processors (DSPs) are another special class ofprocessor. Like the now-removed Blackfin architecture, both the Texas Instruments C6x andQualcomm Hexagon DSPs are capable of running Linux in a limited way, butthis rarely seems to happen. Typically, these processors instead runbare-metal code and communicate with Linux running on an Arm core on thesame chip.
Support for MMU-less processors was merged into Linux-2.5.45 in 2002 andhas been proclaimed to be dying ever since. At its height, 12 MMU-less CPUarchitectures were supported, but most of those are obsolete and no longerwork with mainline kernels. The following are some of the still-supportedSoCs as of Linux-5.10:
J-core FPGA SoC
NXP i.MX RT1050
The most active microcontroller platform running Linux is now the STM32series. These can be even cheaper than the low-end MIPS32 or Armv5 chips,so they are sometimes used when manufacturing cost is more important thanperformance or the additional development effort. Power consumption andphysical size can also be reasons to use them. Some products have shippedrunning inside the built-in 2MB of SRAM, others use external DRAM or PSRAM,which again increases cost.
Kernel support for the i.MX RT series, MT3620, and ESP32 exists out of treebut has not been submitted for inclusion in mainline Linux. The KendryteK210 is special for being a 64-bit MMU-less CPU system; the kernel portmainly exists because there are still no other low-cost RISC-V chips withLinux support. The Mediatek MT3620 is another special case, it is designedfor the Microsoft Azure Sphere and does have an MMU, but runs Linux in only4MB of integrated SRAM.
Linux on microcontrollers competes with a wide range of open-sourcerealtime operating systems includingZephyr,NuttX,Mbed, andFreeRTOS.These tend to need less memory and are better suited for runningwithout a memory-management unit.
Linux on Armv7-A
It's hard to overstate the impact that Armv7 has had on embeddedcomputing. This can be largely attributed to the never-ending demand forfaster and more efficient processors in smartphones. Over the evolutionfrom the high-endNokia N96 in 2008 to this year's Apple iPhone 12, we see a 10x increasein clock frequency, an 8x increase in pipeline width, and a 6x increase inthe number of cores.
The Cortex-A9 managed to surpass practically all competing 32-bit cores ofthe time. It combined the advantages of an out-of-order pipeline, up tofour cores, NEON SIMD, and 40nm manufacturing, and went on to become the mostsuccessful licensable 32-bit CPU core of all time. In Linux-5.10, there are452 devicetree files based on 76 SoCs, or 30 SoC families, far morethan any other Arm core, and more than all non-Arm machines combined.
While the popular Cortex-A9 was the most advanced core in the firstgeneration of Armv7-A, which includes Cortex-A8, Cortex-A5, PJ4, andScorpion, the second generation Armv7VE cores ended up with theopposite situation. The high-end Cortex-A15, Cortex-A17, Brahma-B15, andKrait cores made a big entrance in mobile phones, automotive, and networkingequipment from 2012 to 2013, but as they ran into limitations of the32-bit virtual address space, they were quickly replaced with the emerging64-bit Armv8 based products.
Cortex-A7, in comparison, is a relatively simple, in-order CPU core, but onthe typical 28nm process it beats a 40nm Cortex-A9 in performance andoutclasses it in power consumption and die area. It also offers many of thefeatures of the Armv8 cores that were integrated into Armv7VE:virtualization, large physical address extensions (LPAE), up to eight cores,big.LITTLE configurations, and hardware integer division. Seven years afterits launch, Cortex-A7 remains the most common option for new low-costembedded SoCs with two or four cores, most commonly paired with around256MB of DDR3L memory per core either inside a system-in-package or on the board.
Cortex-A9 and Cortex-A7 together with their 64-bit counterparts havereplaced most other 32-bit architectures in embedded systems, including theMIPS32r2 cores that were common in wireless networking SoCs untilabout 2017. The 64-bit Cortex-A53 is now used in more SoCs than theCortex-A7, but is still behind the Cortex-A9.
There are two obvious factors that will determine the eventual demise ofArmv7-A:
A system that needs more than 2GB of memory orhigher performance than a quad-core Cortex-A7 ends up on 64-bithardware. Cortex-A7 is not available below 28nm semiconductortechnology and loses its cost advantage over 64-bit cores as 22nm and 14nmprocesses get cheaper.The Cortex-A32 core is a 32-bit version of the 64-bit Cortex-A35 that couldtheoretically address both the performance and the manufacturing points,but so far no SoC has been built around it. Apparently there is simply nopoint in using a feature-reduced core when the Cortex-A35 can do all thesame things but also support 64-bit code at only a marginally highercost. This means that, unless a new 32-bit Arm or RISC-V core manages totake over the extreme low end, Cortex-A7 will be the end of the line for32-bit Linux.
This graph shows how many SoCs use each of the Armv7 CPU cores over time asthe kernel adds devicetree source files for each one. Cortex-A9 initiallysaw the highest growth but has stagnated since, along with all cores otherthan the Cortex-A7. This timeline is delayed from the introduction of thehardware because support for older SoCs is sometimes added many years afterthe hardware was built.
Looking at individual boards, there would be an additional delay based onhow long an SoC is used in new products.
It is well understood that many 32-bit systems will stop working in theyear 2038 when the 32-bit time_t overflows. Extrapolating from thecurrent popularity of Armv7 SoCs and the time that chips for older architecturesare getting deployed, it seems likely that 32-bit hardware runningLinux will be sold well into the 2030s and in some cases stay in use fordecades after a product has first shipped, so this is a very real threat.
After years of work, the kernel itself is now completely converted tousing 64-bit time_t internally, and the musl C library hasswitched over, but any distributions based on the GNU C Library (glibc) are stillaffected by this problem and need to be rebuilt against a future version ofthe library once its 64-bit time support has been completed.
The degree to which distributions will be rebuilt is an open question,given the declining interest in 32-bit architectures among developers. Many binarydistributions, like Fedora, Ubuntu, and openSUSE Leap, have dropped supportfor all 32-bit architectures other than Armv7 and are likely to drop thatas well before they would consider rebuilding against a new glibc.
Debian still supports its official ports to Armv5 (armel), Armv7 (armhf),x86-32 (i386), and MIPS32r2 (mipsel), as well as non-official 32-bit portsto PowerPC, SuperH, PA-RISC, Motorola 68000, and x32. The port to Armv7 islikely to outlive all the other architectures the way it did on the otherdistributions, possibly for another ten years after the remaining ones aregone. This means there will likely be embedded users that wantDebian armhf to work beyond 2038.
While there was a plan to moveto a time64 glibc for Debian 11 (Bullseye) on armhf, theearliest possible release is now Debian 12 (Bookworm). There are still openquestions regarding whether this should replace the existing armhf port orwhether it needs to be able to coexist as a multiarch target with a new name andtarget triplet, which adds more work. These questions may become moot ifthere is not enough interest among porters to keep Debian supported on32-bit architectures in the future, which does seem to be a growing problem.
In embedded systems that compile everything from source using theYocto Project,Buildroot,OpenWRT, or similar distributions, thereis usuallyalready an option to use the musl-1.2 library to get full supportfor 64-bit time_t, if this isn't already the default.
When a 32-bit system has more physical RAM than it can map into its linearvirtual address space, anything outside of that linear mapping is calledhighmem and requires using the kmap(), kmap_atomic(),or the newkmap_thread() helpers to be accessible temporarily from kernelcode. Requiring all user-space memory access to be written based on theseinterfaces is a burden to not just 32-bit architectures but also 64-bitones. Given the observation that 32-bit systems with a lot of memory areactually getting rarer over time, the question ofdeprecating highmem comesup on a regular basis.
This is a list of common 32-bit systems with large memory requirements, toshow which machines would be impacted the most from deprecating highmem:
Intel Xeon MP
NXP QorIQ P4080
Intel Axxia 5500
TI Keystone 2
Marvell Armada XP
Nvidia Tegra K1 (T124)
NXP i.MX 6QuadPlus
Samsung Exynos 5800
Intel Core Duo
The largest configurations appear in large server systems that werereplaced with larger, 64-bit server systems many years ago. The same istrue for most 32-bit PC and laptop systems with 2GB of memory ormore. Early Chromebooks used Cortex-A15 or A17 CPU cores with 4GB ofmemory; they have stopped getting software updates in June 2020 but are oftenstill in active use and can run modern Armv7 Linux distributions as along-term alternative.
For embedded industrial and networking systems, 32-bit configurationswith up to 8GB exist and still require future kernel updates, but they arerare as the practical configuration is limited by the available DDR3memory they use. A board with 8GB of DDR3 memory needs eight 8Gb chips that areexpensive and not widely available, or sixteen 4Gb chips in a multi-ranksetup and complex board layout. Later 64-bit SoCs in comparison often useLP-DDR4 memory that supports up to 8GB with a single 64Gb chip.
Configurations with 2GB or 4GB of DDR3 or LP-DDR3 memory are common enough onCortex-A15-based embedded systems that they will have to be supported for along time. Cheaper Cortex-A7 based SoCs, instead, have a single narrowDDR3 interface, which limits the practical configurations to one or twochips with either 2Gb or 4Gb each, and avoids the use of highmem whenall memory fits into a 1GB low-memory area. LP-DDR4 or other technologies thatallow higher capacity are rarely used on these cheapest SoCs, because theytend to be more expensive for small configurations.
A rough plan for removing highmem, based these observations, could unfoldlike this:
Support for highmem gets worse over time, as the kernel is modified towork better on 64-bit systems while adding larger overhead on 32-bitkernels. This can be seen happening with the kmap_thread()addition.
32-Bit machines with the largest memory configurations, includingeverything over 4GB, are rare enough that they can eventually stop gettingkernel updates. Keystone2 and GZ/G1H are among those that still need kernelupdates on 8GB machines for the moment, i.MX6 with 4GB is in a similarsituation.
Compressed swap pages in the highmem area might still be used on laterkernels for that hardware, instead of directly providing high memory pagesto user space.
SoCs based on Armv7VE cores (Cortex-A7, -A15, and A17) inconfigurations with 2-4GB of RAM can move to the work-in-progresssupport for CONFIG_VMSPLIT_4G_4G that will allow accessing closeto 4GB of physical memory while also providing 4GB of virtual memory forprocesses. This comes at a higher performance cost than highmem but, sinceit is basedon features of the Armv7 MMU, will not be nearly as badas the comparable feature that was used on x86 in the past.
The same trick as Armv7VE might also be used on Baikal T1 with itsMIPS32r5 processor, but is harder to implement there. Older MIPS32 machinesonly support up to 512 MB of low memory due to hardware limitations.
Other 32-bit architectures can use CONFIG_VMSPLIT_2G_OPT tomake up to 2GB of physical memory available without highmem support, at thecost of reduced user virtual memory. This would include Cortex-A9 as wellas x86 and PowerPC machines, on which a CONFIG_VMSPLIT_4G_4Goption is unlikely to get implemented because of hardware limitations orlack of interest. If the plans for CONFIG_VMSPLIT_4G_4G work out, less than 1%of the machines should lose support for newer kernels after highmem getsremoved, and that number goes down as time passes. WithoutCONFIG_VMSPLIT_4G_4G on the other hand, losing support for aportion of the 32-bit machines might not be acceptable at all, so highmemwould have to remain an option for as long as users update their Armv7kernels.Either way, this topic will remain interesting for years tocome, as compromises continue to be made based on shifts in priority.
The continued move towards 64-bit hardware means that most users no longerhave to worry about the problems of 32-bit systems such as the time_toverflow and limits of the virtual and physical address space, but this isnot true for everyone. For example:
There are a lot of legacy binaries that users may need to keeprunning, in particular on x86 machines, that have 30 years of backwardcompatibility including games ported from 32-bit Windows
Similarly, Android apps are often still being distributed as32-bit Arm binaries for the widest hardware compatibility in some markets,despite Google's push for apps in its own Play store to be builtfor 64-bit or architecture-independent.
As 64-bit processors take over the low-cost market, they get combinedwith smaller memory configurations, with as little as a single 2Gb DDR3system-in-package configuration for 256MB of physical memory. At thispoint, running 64-bit code has a significant overhead and there is astrong cost incentive to run 32-bit code instead of doubling the memorycapacity.The most common way to deal with this problem is to run a 64-bit kernel but bootinto an unmodified file system containing a 32-bit user space. This worksbecause the kernel has long supported both types of applications byimplementing a second set of system call entry points known simply as the"compat" layer for each interface that is incompatible. Thereare a few exceptions in device drivers that do not support compat tasks,but those are mostly limited to third-party modules outside of the mainlinekernel.
The same compat kernel support allows mixing 32-bit and 64-bit containerinstances, as well as mixing both types of applications inside of a single"multilib" or "multiarch" root filesystem. Usingcompat mode avoids most of the problems with highmem, but still requirescompiling all the 32-bit user application code with a time64-capable Clibrary to be able to run beyond year 2038.
On x86 and MIPS machines, another option is to run a 32-bit kernel directlyon 64-bit hardware, which provides better compatibility with device driversand lets users share both the kernel and root file system across 32-bit and64-bit hardware, but brings back the virtual address limitations of the32-bit kernel and will lack kernel features that are only available in64-bit builds. In theory, this is also possible on many Arm processors, butthere are many limitations:
Armv8 processors lack certaininstructions (setend, cp15 barriers,swp/swpb atomics) that may be used in older 32-bitbinaries. While the 64-bit kernel emulates these in compat mode, the 32-bitkernel emulation is less complete, so existing binaries that work on 64-bitArmv8 kernels as well as 32-bit Armv7 systems might not work on the same32-bit kernel running on Armv8 hardware.
Most CPU implementations require some errata workarounds in the kernelto work correctly. The 32-bit Arm kernel has workarounds for all Armv7cores, but not for Armv8 cores. This can result in undefined behavior anddata corruption in the worst case.
Many security features require 64-bit kernels, either because ofhardware limitations or missing implementation in 32-bit kernels. Thisincludes kernel page-table isolation("Meltdown" protection), kernel address-spacelayout randomization,PAN,UAO,BTI,PTR_AUTH, and hardwarecryptography. Runninga 32-bit kernel can therefore be less secure.
In general, this configuration is not well tested, as kerneldevelopers rightfully point to using 64-bit kernels as a betteralternative.
The latest generation of Armv8.2 cores have dropped hardware supportfor running 32-bit kernels completely. This includes the"little" Cortex-A55 as well as the all "big" coresstarting with Cortex-A76. These can still run 32-bit user space code incompat mode. Some future cores will drop 32-bit user mode as well, butit seems likely that there will still be "little" cores for aslong as there is demand for them. In fact it appears that there will be systems that can run 32-bit code only on some of the cores.
Despite these limitations, there have been large-scale deployments of32-bit Arm kernels on 64-bit hardware, notably in the Raspbian distributionthat manages to use the same code across Armv6 (Raspberry Pi 1 and Zero),Armv7-A (Raspberry Pi 2), and Armv8 (Raspberry Pi 3 and 4),as well as some low-end Android systems that appear to do this primarily to avoid thestricter Generic Kernel Image (GKI) rules that are required for shippingAndroid 10 with 64-bit Arm kernels.
Memory consumption by the kernel itself may turn out to be a reason tofinally add proper support for Armv8 processors to the 32-bit Arm kernel,to squeeze out the few last percent of usable memory in very smallmachines. As an estimate, there are multiple areas in which 64-bit kernelsadd an unavoidable overhead that can amount to dozens of megabytes:
The kernel image itself is roughly 50% larger compared to aThumb2-enabled Armv7 kernel. On a typical configuration, it can grow from10MB to 15MB, or more if the 64-bit configuration includes support foradditional hardware as is the case with Android GKI.
As each 4KB page in the system requires a struct pageentry that is typically 32 bytes larger on 64-bit kernels, one extramegabyte of memory is consumed for each 128MB of installed memory just tostore the mem_map array.
Each thread needs its own kernel stack, which is 16KB instead of8KB. This requires one extra megabyte for every 128 threads.
Page tables need one or two extra indirection levels to describe thelarger virtual address space, adding at least 4KB per process.
Slab caches in the kernel tend to be larger as well; in particular theinode cache can appear to use significant memory resources. Thisis harder to quantify, as the inode cache is dynamically sized; it grows aslong as memory is available but shrinks under memory pressure.
On processors that have no native 32-bit mode, it is also possible todefine an "ILP32"ELF format for 64-bit instructions. This is in fact available on both MIPS under the "n32" name and on x86as "x32". Neither of the two is widely deployed in practice,and the patches to add the same for 64-bit Arm kernels were never merged,in order to avoid fragmenting the ecosystem with incompatible binaryformats.
It appears that the emerging RISC-V SoCs designed to run Linux offer only64-bit mode. All the options available to Arm processors are theoreticallyavailable there as well, but in the absence of an established 32-bit RISC-VLinux ecosystem, it seems the architecture will end up largely skippingthat step entirely and instead accept the higher memoryconsumption. There are a few 32-bit RISC-V cores that include an MMU, suchas Rocket, Andes A25, VexRiscv, and Cloudbear BI-350, but so far, 32-bitRISC-V has only managed to make its way into microcontrollers, and while compat modeis theoretically possible with the architecture, neither the kernel noractual CPU implementations support it. An extreme example here is a recently announced low-cost SoC using a 64-bit RISC-V CPU with as little as64MB of RAM.
For the moment, 64-bit Arm processors hold the advantage over RISC-V,as they have two mature software ecosystems they can run, using morespace-efficient 32-bit user space for machines under 1GB. As memoryrequirements and capacities grow, more applications will run better whenbuilt for 64-bit and this difference becomes less important.
As a general rule, cutting-edge technology is short-lived as it quicklygets replaced with the next generation, while anything that performs itsfunction more cheaply than the competition can remain popular for a longtime, possibly decades. This effect can be seen with Motorola 68000architecture, the Arm9 CPU core, and the Raspberry Pi Zero board, which are alloutliving generations of superior replacements.
This effect gives hope to those waiting for the end of highmem, as the onlyhardware with memory configurations that require it was cutting-edge fiveor more years ago and can be expected to be retired within the next fiveyears.
The MMU-less microcontrollers and the smallest memory configurations forembedded systems may die a different death in the same time frame, as theseare often deployed in highly customized environments without a plan forkernel updates. Once the companies using them have stopped deployingsystems on new kernels, it may finally end, the same way that once-populararchitectures like Arm7TDMI or Blackfin disappeared in Linux.
In between those two extremes are a large number of embedded SoCs that arestill popular today, with Cortex-A7-based designs over time becoming theonly viable option for new 32-bit SoCs. These are cheaper and better thananything below them, while anything more powerful is in turn being replacedby 64-bit products. Once a 64-bit core beats the Cortex-A7 on performance,power consumption, and cost, this last market will move on to that for newproducts and 32-bit Linux kernels will only be needed for supportingexisting users. New board designs are likely to appear for five to tenyears after the last Armv7 chip has been created, but after that it cantake another decade before the remaining users finally stop upgrading theirkernels or replace their hardware. Index entries for this article KernelArchitectures GuestArticlesBergmann, Arnd
Did you like this article? Please accept our trial subscription offer to beable to see more content like it and to participate in the discussion.
(Log in to post comments)