Linux (Kernel)

Linux ( German [li ː nʊks ] ) is an operating system kernel. It was originally developed in 1991 by the Finn Linus Torvalds for the x86 architecture and released under the free GNU General Public License ( GPL). The kernel is used in a variety of operating systems, which are often described himself as Linux.

The name Linux is composed of the name of Linus and the X from Unix and shows the similarity with Unix on. He called in common parlance, not only the Linux kernel itself, but also Linux distributions and Linux -based systems. This led to the GNU / Linux naming controversy.

  • 2.1 version number scheme
  • 2.2 development version
  • 2.3 Maintain the kernel versions
  • 2.4 Versions and History 2.4.1 Chronology
  • 2.4.2 Revision history Version 2.6
  • 2.4.3 Version History Version 2.6
  • 3.1 New process scheduler
  • 3.2 Preemptive Kernel
  • 3.3 Access Control Lists
  • 3.4 Inotify
  • 3.5 Other important changes
  • 4.1 Changes of origin control
  • 4.2 The version control system Git
  • 5.1 Proprietary code and concept of freedom
  • 5.2 The kernel under the GPL 2

Basic technology

Tasks of the kernel

The kernel of an operating system is the hardwareabstrahierende layer, that is, it is the touching down on this basic software a standard interface ( API) that is independent of the computer architecture. The software can then always have access to the interface and does the hardware itself, which it uses to know, not accurate. Linux is a modular monolithic kernel and is responsible for memory management, process management, multi-tasking, load balancing, security enforcement, and input / output operations on different devices.

Programming language

Linux is almost exclusively written in the C programming language, with some GNU C extensions are used. An exception is the architecture-dependent parts of the code ( in arch directory within the Linux source ), such as the beginning of system startup ( boot) is written in assembly language.

Operation

In a strictly monolithic kernel, the entire source code, including all drivers in the kernel image is compiled ( the executable kernel). In contrast, Linux can use modules that can be loaded during operation and removed. This flexibility is achieved in order to address a wide variety of hardware can, without any ( not required ) drivers and other system items in the store having to hold.

Are parts of the hardware specifications not disclosed enough, then Linux based if necessary on special VM86 modes on the system's BIOS, including the enhancements to the standards APM, ACPI and VESA. In order to operate under these conditions x86 - compatible hardware, for example, on the DEC Alpha platform, even emulators to run corresponding ROM codes are partially used. Linux itself takes over the system during the boot process typically in the moment in which the BIOS boot loader was successful and all of the BIOS system initializations have been completed.

The kernel is an operating system kernel, and should not be construed as the real operating system. This consists of the kernel and other basic libraries and programs ( which make the computer operate only ) together.

See also: device file, Network Block Device, Netfilter, network scheduler, process scheduler, Linux ( operating system)

Interfaces

One can distinguish between four interfaces that enable the interaction of either internal kernel components with each other or the kernel and external software. The stability of the external programming interface is guaranteed, that is basically without any source code changes is portable. The stability of the internal programming interface is not guaranteed, they can remain stable for a decade or a few months. Because the Linux kernel is driven by several thousand developers of any resulting expense is to get over.

The binary interface of the kernel is irrelevant to the entire operating system is what matters. The Linux Standard Base (LSB) is to enable commercial programs unchanged porting between Linux operating systems. The internal binary interface is stable, and there are no attempts to change this; this has the consequence that an internal module that has been compiled, for example, for Linux 3.0, will most likely not work with Linux kernel 3.1. This is a deliberate decision.

Architecture

Linux is a monolithic kernel. The driver in the kernel and the kernel modules run in privileged mode (x86: Ring 0), so have unrestricted access to the hardware. A few modules of the kernel running in restricted user mode (x86: Ring 3 ). The Level 1 and 2 of the x86 architecture are not used by Linux, since it should not exist on many other architectures and the kernel on all supported architectures essentially work the same.

Almost every driver can also be available as a module and then loaded dynamically by the system. This does not include drivers that are responsible for starting the system before you can access the file system. One can, however, configure the kernel so that a Cramfs or initramfs file system is loaded before the actual root file system containing the other necessary for the start of the process modules. This allows the kernel size is reduced and the flexibility to be increased dramatically.

In the system, running programs in turn get assigned by the kernel processor time. Each of these processes is given a separate, protected memory space and can only system calls to the device driver and the operating system access. The processes take place in user mode ( user mode ), while the kernel in kernel mode ( kernel mode ) works. The privileges in user mode are very limited. Abstraction and memory protection are almost perfect, a direct access is allowed only very rarely and under precisely controlled conditions. This has the advantage that no program, for example, the system can crash with an error.

Linux provides a complete Unix as its model abstraction and virtualization for almost all of the resources available ( such as virtual memory, illusion of a separate processor, etc. ).

The fact that Linux is not based on a microkernel, has been the subject of a famous flame wars between Linus Torvalds and Andrew S. Tanenbaum. In the early 1990s, when Linux was developed, monolithic kernels were considered obsolete (Linux at this time was still pure monolithic). The discussion and conclusions are described in the article History of Linux closer.

Enhancements such as FUSE and by the increasing use of kernel processes now also flow micro- kernel concepts.

Portability

Although Linus Torvalds had not actually intended to write a portable kernel, Linux has developed far-reaching in that direction, thanks to the GNU compiler GCC. It is now with one of the most widely ported systems ( NetBSD only runs at about the same number of architectures). The repertoire ranges from rarely encountered operating environments such as the iPAQ handheld computers, digital cameras or mainframes such as IBM's System z to normal personal computers ( PCs).

Although the port to the S/390 originally a not approved by IBM management venture was (see also: skunk works), IBM is also planning the next -generation IBM supercomputer Blue Gene with its own Linux port equip.

Originally Torvalds had sought a very different kind of portability for his system, namely, the possibility of free GPL and other open source software easy to compile under Linux. This goal has been achieved very early and certainly makes a good part of the success of Linux, since it each provides an easy way to run on a free system free software.

Linux currently runs on the following architectures:

  • Acorn Archimedes A5000 and Risc PC series ( ARM, StrongARM, Intel XScale, etc.)
  • AMD64 or Intel 64 (often "x86 -64 " or " x64 "): a all x86 processors with 64- bit extension ( still continue to IA- 32 architecture ), as AMD's Athlon 64, Opteron, Turion, Phenom, Phenom II, Bulldozer and Intel's Core 2, Core i, Xeon
  • Atmel AVR32
  • Axis Communications ' CRIS
  • Blackfin
  • Compaq Alpha processor
  • Hitachi H8/300
  • Hewlett -Packard PA -RISC
  • IA- 64: PCs with 64- bit Intel Itanium processor
  • IBM S/390 and System z
  • Intel 80386 ( up to kernel 3.7, in early 2013 ): IBM PCs and compatibles with 80386 - plus compatible x86 processors from the same generation
  • Intel 80486 and later: IBM PCs and compatible with 32- bit processors of the IA- 32 architecture, including Intel 80486 and Pentium, AMD Athlon and Duron, Cyrix processors and many more.
  • Support for Intel 16 -bit CPUs ( 8086, 8088, 80186, 80188 and 80286 ) is being developed as part of the ELKS project. ELKS stands for Embeddable Linux Kernel Subset and is a kernel subset.
  • MIPS machines from Silicon Graphics ...
  • Motorola 68020 and later: later Amiga, Atari some and many Apple Computer in 1987 (Macintosh II) and 1995 (see Linux68k )
  • NEC V850E
  • PowerPC: most of Apple Computer 1994-2006 (all PCI-based Power Macintosh, the Nintendo GameCube, limited support for NuBus Power Macs ), Clones of Power Macs Power Computing, UMAX and Motorola, with a " Power UP" - map enhanced Amigas (such as Blizzard or Cyber ​​Storm ) or its successor AmigaOne, both IBM Power and PowerPC - based IBM RS/6000 systems, various embedded PowerPC platforms
  • Sun SPARC and UltraSPARC: Sun workstations
  • Hitachi SuperH: Sega Dreamcast
  • OpenRISC

Binary interfaces the ARM architecture

Linux supports two different binary interfaces for ARM processors. The older binary interface is referred to by the acronym OABI (old application binary interface) and supports the processor architectures, up to and including ARMv4, while the newer binary interface, which is called with EABI (embedded application binary interface), supports the processor architectures from and including ARMv4. The most significant difference of binary interfaces in terms of system performance is the much better support of software - emulated floating point calculations by EABI.

User Mode Linux

A special port is the User Mode Linux (UML). Basically, it involves a port of Linux to its own system call interface. This makes it possible to launch a Linux kernel as a normal process on a running Linux system. The user-mode kernel then accesses not even on the hardware, but sufficient requirements imposed on the real kernel. This constellation of Java virtual machines or the jails of FreeBSD " sandboxes " similar possible in which a normal user can have root privileges without being able to hurt the actual system.

μClinux

μClinux is a Linux variant for computer without a Memory Management Unit ( MMU) and is mainly used on microcontrollers and embedded systems are used. Since Linux version 2.6 μClinux is part of the Linux project.

Kernel versions

On the website kernel.org all old and new kernel versions are archived. The located there reference kernel are also called vanilla kernel ( from colloquial engl. Standard vanilla or without extras compared to the distribution kernels ). In this so-called distribution kernel build, complemented by individual Linux distributions to other functions. The kernel version of the loaded operating system can be queried with the uname- r command.

Version number scheme

The early versions of the kernel (0.01 to 0.99 ) still had no clear numbering scheme. Version 1.0 should be " stable " version of Linux the first. Starting with version 1.0, the version numbers of Linux follow a certain pattern:

The first digit is raised only if fundamental changes in the system architecture. During the development of the unstable 2.5 kernel came because of the relatively fundamental changes compared to the 2.4 kernel to declare the discussion among the kernel programmers, the next production kernel 3.0. Torvalds was, however, for various reasons, however, such that the resultant kernel is referred to as 2.6.

The second number indicates the particular "Major Release ". Previously versions were stable (so-called kernel production ) are always marked by the developers by even numbers such as 2.2, 2.4 and 2.6, while the test versions (called kernel developers ) always wore odd numbers, such as 2.3 and 2.5; this separation is suspended since July 2004, there was no development kernel with the number 2.7, the changes were instead continually incorporated into the 2.6 series.

In addition, a third number refers to the " Minor Release ", which identifies the actual version. When adding new features to the third number increases. The kernel is determined so that, for example, with a version number such as 2.6.7.

In order to spread the correction of a serious NFS error more quickly, a fourth digit was introduced with version 2.6.8.1 for the first time. Since March 2005 (kernel 2.6.11 ), this numbering is officially used. Thus, it is possible to guarantee the stability of the kernel, despite some very fast release cycles and take corrections of critical errors within a few hours into the official kernel - where the fourth digit increases (eg from 2.6.11.1 to 2.6.11.2 ). The minor release number, so the third digit is incremented, however, only with the introduction of new functions.

In May 2011, Linus Torvalds did not explain that coming after version 2.6.39 version 2.6.40, but also to designate 3.0. The reason he argued that the version numbers in his opinion, were too high. The version number '3 ' would simultaneously represent the third decade, which will begin for the Linux kernel with his 20th birthday. In the future, the second digit is increased with new versions, and the third is - instead of as before the fourth - for bugfix releases.

Development version

New functions can be found in the so-called - mm kernel of kernel developer Andrew Morton and are then transferred to the main branch of Torvalds. Thus, large differences between development and production kernel and related porting problems between the two series are avoided. By this method, there are fewer differences between the official kernel and the distribution kernel (previously were features of the development branch of the distributors often reintegrated into their own kernel). However, 2004/2005 suffered the stability of the 2.6 kernel under the often too fast uncommitted changes. End of July 2005, therefore, a new development model, it was decided for the first time comes after the release of version 2.6.13 used: innovations are accepted only in the first two weeks of kernel development, which is then carried out a quality assurance to the final release of the new version.

Maintenance of kernel versions

While Torvalds released the latest development versions, care for the older "stable" versions was given to other programmers. Currently, David Weinehall is responsible for the 2.0er series, Marc- Christian Petersen (formerly Alan Cox ) for the 2.2 kernel, Willy Tarreau ( Marcelo Tosatti previously ) for the 2.4 kernel, Greg Kroah- Hartman and Chris Wright for the current stable kernel 3. xy ( - stable), Linus Torvalds for the current "normal" kernel 3.xy, and Andrew Morton for his experimental -mm branch, based on the latest 3.x. In addition to these official and Kernel.org or one of its mirrors to be purchased kernel source, you can also use alternative " kernel Trees" from other sources. Distributors of Linux -based operating systems usually maintain their own versions of the kernel and employ for this purpose salaried kernel hackers who let their changes usually also feed into the official kernel.

Distribution kernels are often intensively patched to contain drivers that are not yet included in the official kernel from which the distributor but believes that his customers could need and the necessary stability, respectively, accuracy is still guaranteed.

Versions and version history

Chronology

The graph represents individual versions of the Linux kernel is arranged based on the release dates on a time table and will serve the overview.

Revision history Version 2.6

Version History Version 2.6

Looking at the latest published versions ( see table ), the development of a new kernel version in an average of 82 days. The kernel is hereby extended by an average of 768 files and 325 892 lines of code (English Lines of Code ). The pack with the gzip compressed tar archive (. Tar.gz ) grows on average around 2 megabytes with each published major version.

New lines of source code ( b )

Increase of the archive file size in kB ( c )

Development periods

Comments

What's New in 2.6 kernel

The kernel series 2.6 was developed from December 2001 on the basis of that the 2.4 series and had extensive innovations. For the development of new code was clearer and easier to maintain, while users benefited by the revision of the so-called process scheduler and the I / O area and lower latency. This has been achieved by a number of measures which are shown below:

New process scheduler

In a multitasking -capable operating system, there must be an entity that allocates the processes that want to run, computing time. This instance is the process scheduler. Since the release of Linux 2.6 has repeatedly worked fundamentally on the scheduler.

For the first 2.6 kernel compared with a completely new Linux 2.4 scheduler by Ingo Molnar had been designed and implemented, the so-called O (1) scheduler. This got its name because the relevant algorithms, based on which the scheduler to have the time complexity. This means that the processing time required by the scheduler for its own functions regardless of the number of the managed process or thread. In particular it was about to dispense with the search of all processes after the currently most important process.

The O (1) scheduler worked very efficiently even at very many processes and required even very little computation time. He used basically two linked lists in which the processes were registered, which wanted to run, and those that have already run. If all processes were in the second list, the data fields were changed, and the game began again. The scheduler was also designed so that processes that take large amounts of computing time want to be disadvantaged in relation to interactive processes when both want to run at the same time.

Interactive processes require very little processing time generally, but include time-critical ( so the user does not want to, for example, long wait for a response from the graphical user interface ). The O (1) scheduler possessed heuristics to determine if a process is interactive or hog the CPU rather long.

The internal " clock " of the kernel has been increased from the 2.6 kernel from 100 to 1000 hertz, that is, the shortest possible length of a time slice is now a millisecond. Also benefit from this especially the interactive processes, because they are " back to the series' past. However, since this leads to an increased CPU load and thus to a larger power consumption, it was decided, the clock from kernel 2.6.13 on 250 Hertz preset. When configuring the kernel, but also the values ​​100, 300 and 1000 Hz are selectable.

With kernel version 2.6.23 (short CFS) was established in October 2007, the O (1) scheduler by a so-called Completely Fair Scheduler replaced, which was also developed by Ingo Molnar. The CFS as currently only the main development branch of available scheduler is partially controversial among kernel developers, as it focuses on scalability on servers with many cores. Developers such as Con Kolivas are of the opinion that under this priority, as well as some design decisions in the CFS suffer performance on typical desktop systems.

Preemptive kernel

The kernel is preempted in most of the features from version 2.6, which means that even if the system performs tasks just in kernel mode, this operation can be interrupted by a process from the user mode. The kernel makes then when the user -mode process has used up its time slice or even a new scheduling (English Re -Schedule ) requests, so the scheduler (English Scheduler) tells you that it can perform another task. This works, except for some kernel functions (not interruptible) must run atomically, very good and also benefits of interactivity.

Access Control Lists

With the 2.6 kernel will be the first time for Linux Access Control Lists ( english, access control lists ) introduced natively. These very fine-grained rights management makes it especially system administrators to configure the rights on a file system regardless of the group and user model and to set virtually any number of specific rights per file. The lack of support for access control lists of Linux was previously seen as a massive weakness of the system in the context of rights management and the possibilities for secure configuration.

Support for access control lists work this natively with file systems ext2, ext3, jfs, and xfs.

Inotify

With the 2.6.13 kernel for the first time held a inotify mechanism called feeder into the kernel. This makes for permanent monitoring of files and directories: If any of the monitored objects changed or create a new object in the interstitial space, Inotify displays a message, which in turn can cause other programs to defined activities. This is particularly important for search and indexing mechanisms of the data sets is of crucial importance, and only allows the meaningful use of desktop search engines like Strigi or Meta Tracker. Without such notification feature of the kernel, a process would need to be monitored file or directory to be monitored at specific time intervals to check for changes, which is in contrast to inotify would bring additional performance hit with it.

Other important changes

Insofar as possible, the maximum number for certain resources was raised in Linux 2.6. The number of potential users and groups increased from 65,000 to over 4 billion, as well as the number of process IDs ( from 32,000 to 1 billion ) and the number of devices ( major / minor numbers ). Other performance-enhancing measures related to the I / O scheduler, the threading with the new Native POSIX Thread Library and the network stack, which is scaled now also in most tests O (1). In addition, the I / O device files was formerly used devfs replaced by the newer udev to manage what many shortcomings, such as too great a / dev / directory removed. In addition thus allows uniform and consistent device naming that remain unchanged, which was not the case before.

Development process

The development of Linux is not in the hands of individuals, corporations or countries, but in the hands of a global community of many programmers who exchange mainly via the Internet by the GNU General Public License and a very open development model. In many mailing lists, but also in forums and on Usenet, there is the possibility to follow the discussions about the kernel, to participate in it and to also make active contributions to the development for everyone. Through this simple procedure, a fast and steady development is ensured, which also brings with it the possibility that anyone can make available to the kernel skills he needed.

This is Bounded only by the control of Linus Torvalds and some particularly deserved programmers, who have the final word on the inclusion of improvements and patches in the official version. Some Linux distributors build a your own functions in the kernel, which are included in the official kernel (yet) available.

Changes in the origin control

The development process of the kernel has also continued to develop as the kernel itself. So led the legal process of SCO Group allegedly illegally transmitted code in Linux imposing a "Linux Developer 's Certificate of Origin ", which was announced by Linus Torvalds and Andrew Morton. This change took up the problem that after the hitherto valid model of the Linux development process, the origin of an expansion or improvement of the kernel could not be traced.

"These days, most of the patches in the kernel do not Actually get sent directly to me. That not just would not scale, but the fact is, there 's a lot of subsystems I have no clue about, and ran thus no way of judging how good the patch is. So I end up seeing mostly the maintainers of the subsystem, and when to find an error happens, what I want to see is the maintainer name, not a random developer who I do not even know if he is active any more. So at least for me, the _chain_ is mostly more important than Actually the actual originator.

There is therefore another issue, namely the fact than when i (or anybody else, for that matter ) to get emailed patch, the only thing I can see is the Directly sender information, and that's the part I trust. When Andrew sends me a patch, I trust it Because it comes from him - even if the original author 'may be somebody I do not know. So the _path_ the patch came in through Actually documents did chain of trust - we all tend to know the "next hop ", but we do _not_ Necessarily have direct knowledge of the full chain.

So what I'm Suggesting is did we start "signing off" on patches, to show the path it has come through, and to document did chain of trust. It thus Allows middle parties to edit the patch without somehow "losing " their names -. Quite Often the patch did Reaches the final kernel is not exactly the same as the original one, as it has gone through a few layers of people "

"At the moment, most are not sent patches to the kernel directly to me. That would simply not feasible. The fact is that there are a lot of sub- systems with which I am not familiar, so I have no way to determine how good the patch is. Therefore, it usually runs out on meeting the caregiver ( maintainer ) of the subsystem. If an error occurs, I want to see the name of a nurse and not just any developer, and I do not even know if he is still active. Therefore, the _Kette_ for me is definitely more important than the actual author. Also there is another problem, namely, that I, me if you (or anyone else ) a patch over e- mail sent, only the sender information can be seen directly, and that's the part that I do not trust. When Andrew sent me a patch, I trust the patch, because it comes from Andrew - even if the original author is someone I do not know. So actually occupied the _Weg_, the patch took to me, this chain of trust - we all tend to know the respective next " link", but to have _not_ necessarily direct knowledge of the entire chain. So what I suggest is that we start Patches " emerge " in order to show the path they have taken and to document the chain of trust. This allows beyond promoting groups to change the patch without giving the name of someone " by the wayside " - quite often is the patch version, which is incorporated ultimately into the kernel, not just the original, it is still by some developers layers gone. "

The version control system Git

The version of the kernel is subject to the control program git This was especially developed for the kernel and optimized for their needs out. It was introduced in April 2005, having signed off that the old version control system BitKeeper for kernel development would not be long can be used.

Special License

Proprietary code and concept of freedom

The issued today by Linus Torvalds version of the kernel contains proprietary objects in machine language (BLOBs) and is not, therefore, entirely Free Software. Richard Stallman doubted even that they may be legally copied, as these BLOBs are contrary to the GPL and the rights of the GPL would therefore expire. As a result it advises the Free Software Foundation, therefore, to use only BLOB - free versions of Linux, in which these components were removed. The makers of the Debian distribution have decided to handle this so.

The kernel under the GPL 2

The usual at GPL Software clause that instead of version 2 of the GPL also a newer version can be used, is missing in the Linux kernel. The decision as to whether the notice published in the June 2007 version 3 of the License for Linux is used so that is possible only with the consent of all the developers in principle. In a survey Torvalds and most other developers have expressed a license for the maintenance of version 2.

414405
de