GNU or Linux?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
No other system has experienced so much controversy over its name. A great many flame wars have erupted over the Free Software Foundation's suggestion that distributions such as Ubuntu and Fedora should be called GNU/Linux, rather than Linux. Are they just trying to take credit for other peoples' work, or is their argument valid?
To try to address this question, let's take a look at what happens when you boot and run a GNU/Linux system—how much GNU and how much Linux code is involved? A developer comes into contact with a huge amount of GNU code; for example, the GNU Compiler Collection (GCC) and GNU Make, but how much is relevant to the end user?
What Does a Kernel Do?
Before trying to work out which bits are GNU and which bits are Linux, it's important to understand exactly what a kernel does. The point of a kernel is twofold:
- Freeing developers from any need to know about the underlying architecture. This goal requires a lot of device drivers and a uniform interface to those drivers. A good example is the socket interface. When you write networked code, you just open a socket and write data to it. You don't need to be aware of the kind of network hardware the user has, or even of the underlying protocol.
- Isolating running programs from each other. Isolating processes from each other in a hardware-independent way is easy: Let the processes use only the unprivileged subset of the CPU's instructions. Unfortunately, this approach prevents a program from doing any kind of I/O, which basically restricts you to running entirely pointless programs. The solution to this restriction is the system call, a mechanism whereby a running process can ask the kernel to perform some privileged operation on behalf of the requesting process. Common examples include writing to a file (a virtualized disk), requesting some memory, or accessing the screen and keyboard.
The exact mechanism that a system call uses is platform-dependent. On x86, the common way was to raise an interrupt, although new AMD and Intel CPUs provide (different) instructions for doing it faster. When this happens, control jumps to the kernel, which chooses how to interpret the values in registers and on the stack, and what action to perform.