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?

  • A kernel is more than a hardware abstraction, i.e., an interface to the hardware. It handles processes, file systems, network, ... Apr 8 at 5:35
  • What's the "platform" you're referring to here? Because that function is a Linux kernel symbol, i.e., Linux implements that itself, and you're right, it needs to implement it in a way that fits the way it uses the memory manager hardware component in a given computer architecture. Apr 8 at 5:37
  • It's not clear what you mean with "input". Linux distributions have huge catalogues of software, and that includes the Linux kernel, which they all build from source, so I think, no, no Linux distro needs any compiled binary as "input". It's not quite clear what you mean, but that seems to be wrong. Can you tell us what you've been reading? Maybe we can try to make sense of what you mean. Apr 8 at 5:39
  • Your last question ("For example...") is a completely new one, and it's not clear what you mean with "this binary". Apr 8 at 5:41
  • "Linux From Scracth (]LFS](linuxfromscratch.org)) is a project that provides you with step-by-step instructions for building your own custom Linux system, entirely from source code." Build that, and you have your own runnable OS. If you want to build a distro based on some specific flavor like Debian, Slackware, Gentoo, Ubuntu, Arch... all major distros have comprehensive documentation that'll help you build what you need / want. Apr 8 at 5:47

1 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:

Graph of the percentage of packages built for each Debian architecture

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:

Graph of the percentage of packages built for each Debian Ports architecture

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .