How do distributions of Linux adopt new targets

Question

My understanding is that distributions like Ubuntu are built on top of the Linux kernel, and the kernel itself is just an interface to a platform's hardware. For example, the Linux source demands a platform implement certain functions like raw_copy_from_user. Once a platform adheres to this interface, we can compile it. Now, is it right to think of a distribution as additional code that expects this compiled binary as input to build? In which case, will any compiled binary work as input?

For example, let's say I develop a new platform and put all necessary code in arch/ for the kernel to compile. How then would I use this binary and an existing distributions to build a runnable OS on my platform?

Answer 1

There are several steps involved to provide a new platform in a distribution, and the first one isn’t the kernel:

1. You need to be able to build programs for the platform, which means you need a compiler (and an assembler); for systems using GCC, that means you need to have Binutils and GCC available for the platform.

2. Once you have a compiler, you need a C library; only then will you have everything needed to build regular C programs.

3. With all that, you can start cross-compiling programs for your new platform; this is how platform initialisation is usually done — you won’t have a working environment on the new platform initially, you need to build it on another system.

4. As soon as you have a C compiler, before even the C library, you can start working on the kernel; most of the kernel is platform agnostic, but you’ll need to add a new arch sub-directory and implement everything needed for the new platform (system initialisation, memory management, the system call interface, etc.). The Linux kernel’s build infrastructure has great support for cross-compiling, which is helpful even after architecture bring-up — embedded systems in particular benefit from being able to build their kernels on much faster systems.

5. The last part in platform bring-up is booting — you’ll need a boot loader of some kind, the details of which are likely to be platform-specific.

6. At this point you should be able to build the core of a distribution, at least enough to get a build environment running on the new platform, which will allow you to start building programs natively on the new platform. (Cross-compiling doesn’t work for everything.)

In a distribution context, once a build environment can be run on the new platform, you’d typically make it available to the general build infrastructure used by the distribution, and start building the distribution’s packages. You can see this in action on Debian Ports and the buildd stats — look in particular at the package availability graphs:

The vertical lines indicate when a new architecture is brought up; there’s a quick ramp-up with all the packages that build “easily” for the new architecture, then varying progress towards 100%. (An architecture can never reach 100% because some packages are architecture-specific.)

The graph for unofficial architectures is also interesting:

Up-and-coming architectures like riscv64 can easily be identified, as can dying architectures like hppa.