Anatomy of the Linux kernel History and architectural decomposition
M. Tim Jones (mtj@mtjones.com), Consultant Engineer, Emulex Corp.
06 Jun 2007
The Linux® kernel is the core of a large and complex operating system, and while it's huge, it is well organized in terms of subsystems and layers. In this article, you explore the general structure of the Linux kernel and get to know its major subsystems and core interfaces. Where possible, you get links to other IBM articles to help you dig deeper.
Given that the goal of this article is to introduce you to the Linux kernel and explore its architecture and major components, let's start with a short tour of Linux kernel history, then look at the Linux kernel architecture from 30,000 feet, and, finally, examine its major subsystems. The Linux kernel is over six million lines of code, so this introduction is not exhaustive. Use the pointers to more content to dig in further.
A short tour of Linux history
 | Linux or GNU/Linux?
You've probably noticed that Linux as an operating system is referred to in some cases as "Linux" and in others as "GNU/Linux." The reason behind this is that Linux is the kernel of an operating system. The wide range of applications that make the operating system useful are the GNU software. For example, the windowing system, compiler, variety of shells, development tools, editors, utilities, and other applications exist outside of the kernel, many of which are GNU software. For this reason, many consider "GNU/Linux" a more appropriate name for the operating system, while "Linux" is appropriate when referring to just the kernel. |
|
While Linux is arguably the most popular open source operating system, its history is actually quite short considering the timeline of operating systems. In the early days of computing, programmers developed on the bare hardware in the hardware's language. The lack of an operating system meant that only one application (and one user) could use the large and expensive device at a time. Early operating systems were developed in the 1950s to provide a simpler development experience. Examples include the General Motors Operating System (GMOS) developed for the IBM 701 and the FORTRAN Monitor System (FMS) developed by North American Aviation for the IBM 709.
In the 1960s, Massachusetts Institute of Technology (MIT) and a host of companies developed an experimental operating system called Multics (or Multiplexed Information and Computing Service) for the GE-645. One of the developers of this operating system, AT&T, dropped out of Multics and developed their own operating system in 1970 called Unics. Along with this operating system was the C language, for which C was developed and then rewritten to make operating system development portable.
Twenty years later, Andrew Tanenbaum created a microkernel version of UNIX®, called MINIX (for minimal UNIX), that ran on small personal computers. This open source operating system inspired Linus Torvalds' initial development of Linux in the early 1990s (see Figure 1).
Figure 1. Short history of major Linux kernel releases 
Linux quickly evolved from a single-person project to a world-wide development project involving thousands of developers. One of the most important decisions for Linux was its adoption of the GNU General Public License (GPL). Under the GPL, the Linux kernel was protected from commercial exploitation, and it also benefited from the user-space development of the GNU project (of Richard Stallman, whose source dwarfs that of the Linux kernel). This allowed useful applications such as the GNU Compiler Collection (GCC) and various shell support.
Introduction to the Linux kernel
Now on to a high-altitude look at the GNU/Linux operating system architecture. You can think about an operating system from two levels, as shown in Figure 2.
Figure 2. The fundamental architecture of the GNU/Linux operating system 
| Methods for system call interface (SCI)
In reality, the architecture is not as clean as what is shown in Figure 2. For example, the mechanism by which system calls are handled (transitioning from the user space to the kernel space) can differ by architecture. Newer x86 central processing units (CPUs) that provide support for virtualization instructions are more efficient in this process than older x86 processors that use the traditional int 80h method. |
|
At the top is the user, or application, space. This is where the user applications are executed. Below the user space is the kernel space. Here, the Linux kernel exists.
There is also the GNU C Library (glibc). This provides the system call interface that connects to the kernel and provides the mechanism to transition between the user-space application and the kernel. This is important because the kernel and user application occupy different protected address spaces. And while each user-space process occupies its own virtual address space, the kernel occupies a single address space. For more information, see the links in the Resources section.
The Linux kernel can be further divided into three gross levels. At the top is the system call interface, which implements the basic functions such as read and write. Below the system call interface is the kernel code, which can be more accurately defined as the architecture-independent kernel code. This code is common to all of the processor architectures supported by Linux. Below this is the architecture-dependent code, which forms what is more commonly called a BSP (Board Support Package). This code serves as the processor and platform-specific code for the given architecture.
Properties of the Linux kernel
When discussing architecture of a large and complex system, you can view the system from many perspectives. One goal of an architectural decomposition is to provide a way to better understand the source, and that's what we'll do here.
The Linux kernel implements a number of important architectural attributes. At a high level, and at lower levels, the kernel is layered into a number of distinct subsystems. Linux can also be considered monolithic because it lumps all of the basic services into the kernel. This differs from a microkernel architecture where the kernel provides basic services such as communication, I/O, and memory and process management, and more specific services are plugged in to the microkernel layer. Each has its own advantages, but I'll steer clear of that debate.
Over time, the Linux kernel has become efficient in terms of both memory and CPU usage, as well as extremely stable. But the most interesting aspect of Linux, given its size and complexity, is its portability. Linux can be compiled to run on a huge number of processors and platforms with different architectural constraints and needs. One example is the ability for Linux to run on a process with a memory management unit (MMU), as well as those that provide no MMU. The uClinux port of the Linux kernel provides for non-MMU support. See the Resources section for more details.
Major subsystems of the Linux kernel
Now let's look at some of the major components of the Linux kernel using the breakdown shown in Figure 3 as a guide.
Figure 3. One architectural perspective of the Linux kernel 
System call interface
The SCI is a thin layer that provides the means to perform function calls from user space into the kernel. As discussed previously, this interface can be architecture dependent, even within the same processor family. The SCI is actually an interesting function-call multiplexing and demultiplexing service. You can find the SCI implementation in ./linux/kernel, as well as architecture-dependent portions in ./linux/arch. More details for this component are available in the Resources section.
Process management
| What is a kernel?
As shown in Figure 3, a kernel is really nothing more than a resource manager. Whether the resource being managed is a process, memory, or hardware device, the kernel manages and arbitrates access to the resource between multiple competing users (both in the kernel and in user space). |
|
Process management is focused on the execution of processes. In the kernel, these are called threads and represent an individual virtualization of the processor (thread code, data, stack, and CPU registers). In user space, the term process is typically used, though the Linux implementation does not separate the two concepts (processes and threads). The kernel provides an application program interface (API) through the SCI to create a new process (fork, exec, or Portable Operating System Interface [POSIX] functions), stop a process (kill, exit), and communicate and synchronize between them (signal, or POSIX mechanisms).
Also in process management is the need to share the CPU between the active threads. The kernel implements a novel scheduling algorithm that operates in constant time, regardless of the number of threads vying for the CPU. This is called the O(1) scheduler, denoting that the same amount of time is taken to schedule one thread as it is to schedule many. The O(1) scheduler also supports multiple processors (called Symmetric MultiProcessing, or SMP). You can find the process management sources in ./linux/kernel and architecture-dependent sources in ./linux/arch). You can learn more about this algorithm in the Resources section.
Memory management
Another important resource that's managed by the kernel is memory. For efficiency, given the way that the hardware manages virtual memory, memory is managed in what are called pages (4KB in size for most architectures). Linux includes the means to manage the available memory, as well as the hardware mechanisms for physical and virtual mappings.
But memory management is much more than managing 4KB buffers. Linux provides abstractions over 4KB buffers, such as the slab allocator. This memory management scheme uses 4KB buffers as its base, but then allocates structures from within, keeping track of which pages are full, partially used, and empty. This allows the scheme to dynamically grow and shrink based on the needs of the greater system.
Supporting multiple users of memory, there are times when the available memory can be exhausted. For this reason, pages can be moved out of memory and onto the disk. This process is called swapping because the pages are swapped from memory onto the hard disk. You can find the memory management sources in ./linux/mm.
Virtual file system
The virtual file system (VFS) is an interesting aspect of the Linux kernel because it provides a common interface abstraction for file systems. The VFS provides a switching layer between the SCI and the file systems supported by the kernel (see Figure 4).
Figure 4. The VFS provides a switching fabric between users and file systems 
At the top of the VFS is a common API abstraction of functions such as open, close, read, and write. At the bottom of the VFS are the file system abstractions that define how the upper-layer functions are implemented. These are plug-ins for the given file system (of which over 50 exist). You can find the file system sources in ./linux/fs.
Below the file system layer is the buffer cache, which provides a common set of functions to the file system layer (independent of any particular file system). This caching layer optimizes access to the physical devices by keeping data around for a short time (or speculatively read ahead so that the data is available when needed). Below the buffer cache are the device drivers, which implement the interface for the particular physical device.
Network stack
The network stack, by design, follows a layered architecture modeled after the protocols themselves. Recall that the Internet Protocol (IP) is the core network layer protocol that sits below the transport protocol (most commonly the Transmission Control Protocol, or TCP). Above TCP is the sockets layer, which is invoked through the SCI.
The sockets layer is the standard API to the networking subsystem and provides a user interface to a variety of networking protocols. From raw frame access to IP protocol data units (PDUs) and up to TCP and the User Datagram Protocol (UDP), the sockets layer provides a standardized way to manage connections and move data between endpoints. You can find the networking sources in the kernel at ./linux/net.
Device drivers
The vast majority of the source code in the Linux kernel exists in device drivers that make a particular hardware device usable. The Linux source tree provides a drivers subdirectory that is further divided by the various devices that are supported, such as Bluetooth, I2C, serial, and so on. You can find the device driver sources in ./linux/drivers.
Architecture-dependent code
While much of Linux is independent of the architecture on which it runs, there are elements that must consider the architecture for normal operation and for efficiency. The ./linux/arch subdirectory defines the architecture-dependent portion of the kernel source contained in a number of subdirectories that are specific to the architecture (collectively forming the BSP). For a typical desktop, the i386 directory is used. Each architecture subdirectory contains a number of other subdirectories that focus on a particular aspect of the kernel, such as boot, kernel, memory management, and others. You can find the architecture-dependent code in ./linux/arch.
Interesting features of the Linux kernel
If the portability and efficiency of the Linux kernel weren't enough, it provides some other features that could not be classified in the previous decomposition.
Linux, being a production operating system and open source, is a great test bed for new protocols and advancements of those protocols. Linux supports a large number of networking protocols, including the typical TCP/IP, and also extension for high-speed networking (greater than 1 Gigabit Ethernet [GbE] and 10 GbE). Linux also supports protocols such as the Stream Control Transmission Protocol (SCTP), which provides many advanced features above TCP (as a replacement transport level protocol).
Linux is also a dynamic kernel, supporting the addition and removal of software components on the fly. These are called dynamically loadable kernel modules, and they can be inserted at boot when they're needed (when a particular device is found requiring the module) or at any time by the user.
A recent advancement of Linux is its use as an operating system for other operating systems (called a hypervisor). Recently, a modification to the kernel was made called the Kernel-based Virtual Machine (KVM). This modification enabled a new interface to user space that allows other operating systems to run above the KVM-enabled kernel. In addition to running another instance of Linux, Microsoft® Windows® can also be virtualized. The only constraint is that the underlying processor must support the new virtualization instructions. See the Resources section for more information.
Resources Learn
- The GNU site describes the GNU GPL that covers the Linux kernel and most of the useful applications provided with it. Also described is a less restrictive form of the GPL called the Lesser GPL (LGPL).
- UNIX, MINIX and Linux are covered in Wikipedia, along with a detailed family tree of the operating systems.
- The GNU C Library, or glibc, is the implementation of the standard C library. It's used in the GNU/Linux operating system, as well as the GNU/Hurd microkernel operating system.
- uClinux is a port of the Linux kernel that can execute on systems that lack an MMU. This allows the Linux kernel to run on very small embedded platforms, such as the Motorola DragonBall processor used in the PalmPilot Personal Digital Assistants (PDAs).
- "Kernel command using Linux system calls" (developerWorks, March 2007) covers the SCI, which is an important layer in the Linux kernel, with user-space support from glibc that enables function calls between user space and the kernel.
- "Inside the Linux scheduler" (developerWorks, June 2006) explores the new O(1) scheduler introduced in Linux 2.6 that is efficient, scales with a large number of processes (threads), and takes advantage of SMP systems.
- "Access the Linux kernel using the /proc filesystem" (developerWorks, March 2006) looks at the /proc file system, which is a virtual file system that provides a novel way for user-space applications to communicate with the kernel. This article demonstrates /proc, as well as loadable kernel modules.
- "Server clinic: Put virtual filesystems to work" (developerWorks, April 2003) delves into the VFS layer that allows Linux to support a variety of different file systems through a common interface. This same interface is also used for other types of devices, such as sockets.
- "Inside the Linux boot process" (developerWorks, May 2006) examines the Linux boot process, which takes care of bringing up a Linux system and is the same basic process whether you're booting from a hard disk, floppy, USB memory stick, or over the network.
- "Linux initial RAM disk (initrd) overview" (developerWorks, July 2006) inspects the initial RAM disk, which isolates the boot process from the physical medium from which it's booting.
- "Better networking with SCTP" (developerWorks, February 2006) covers one of the most interesting networking protocols, Stream Control Transmission Protocol, which operates like TCP but adds a number of useful features such as messaging, multi-homing, and multi-streaming. Linux, like BSD, is a great operating system if you're interested in networking protocols.
- "Anatomy of the Linux slab allocator" (developerWorks, May 2007) covers one of the most interesting aspects of memory management in Linux, the slab allocator. This mechanism originated in SunOS, but it's found a friendly home inside the Linux kernel.
- "Virtual Linux" (developerWorks, December 2006) shows how Linux can take advantage of processors with virtualization capabilities.
- "Linux and symmetric multiprocessing" (developerWorks, March 2007) discusses how Linux can also take advantage of processors that offer chip-level multiprocessing.
- "Discover the Linux Kernel Virtual Machine" (developerWorks, April 2007) covers the recent introduction of virtualization into the kernel, which turns the Linux kernel into a hypervisor for other virtualized operating systems.
- Check out Tim's book GNU/Linux Application Programming for more information on programming Linux in user space.
- In the developerWorks Linux zone, find more resources for Linux developers, including Linux tutorials, as well as our readers' favorite Linux articles and tutorials over the last month.
- Stay current with developerWorks technical events and Webcasts.
Get products and technologies- Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
DiscussGet involved in the
developerWorks community through our developer blogs, forums, podcasts, and community topics in our new
developerWorks spaces.
July 22nd, 2007 at 10:02
[…] Estaba esta mañana leyendo las noticias en OS News y me he encontrado con la grata noticia de que por fin se podrán incluir controladores en espacio de usuario en el núcleo Linux. […]
July 22nd, 2007 at 10:02
Nice!
I hope for a Linux micro-kernel in the future, with all this cool features!
July 22nd, 2007 at 10:23
I think this stable API is a huge chance for Linux. Of course it would be much better if the hardware vendors published free Linux drivers. However, in my opinion, it is better to increase the Linux market share by making it easier to provide proprietary drivers instead of inhibiting people to use Linux by not supporting their hardware. Maybe, in the future Linux will be strong enough to force hardware vendors to publish Open Source drivers, but this point is IMO not yet reached, so we should - as I already said - accept unfree drivers at the expense of not (yet) having a completely free system.
July 22nd, 2007 at 11:05
“”it is better to increase the Linux market share by making it easier to provide proprietary drivers instead of inhibiting people to use Linux by not supporting their hardware.”"
Besides the ‘moral’ ‘Free software’ gnu-style arguements against proprietary software, there are serious technical and practical issues against proprietary drivers.
Mainly they revolve around the fact that if there is something wrong with them, nobody can fix them. Nobody knows how they work, nobody knows how the hardware works, so if the driver breaks for you nobody from Ubuntu or Redhat or Kernel.org will be able to help you. Unless you can get a hold of the original (most of time nameless) developer working at broadcom or ATI then your up shit’s creek without a paddle.
Ever try to get a hold of a developer from ATI to fix a driver issue that only affects you and your paticular hardware/software combination? Either in Windows or Linux? Or nvidia? Or Texas Instruments? Ya, email their customer service and just see how little they care about you. Your not worth their time. Unless it affects a significant number of users they aren’t going to fix it. It’s not worth their time.
In comparision with open source drivers I’ve gotten attention from the people that wrote them. I filed bugs, they fixed them. Every day people working on Ubuntu or Debian submit patches and different fixes to various drivers.
This is why Redhat refuses to support hardware configurations that require proprietary drivers. This is why Dell will refuse to ship server hardware that uses proprietary drivers. They know and understand this in the server room.. Linux with open source drivers is significantly cheaper for both the end user and the OEM to support then Linux with closed source drivers.
The Linux developers do require the assistance of the hardware manufactures to create full featured drivers in a timely fasion. If not then it requires reverse engineering and the drivers are going to lag behind.. like Open source 3d drivers for Nvidia and ATI. So it creates the illusion that Linux devs aren’t able to keep up with and create quality drivers sometimes.. But this is, indeed, a illusion.
For both the end user, the hardware manufacturer, and the people that need to do commercial support Linux with OSS drivers has a significant advantage in stability, ease of use, and often performance. This advantage is one of things that will make Linux much more appealing for end users versus Windows.
All of this is purely technical, it still doesn’t take into effect any sort of moral, ethical, or legal reasons for not using proprietary drivers.
So saying that Linux needs to support proprietary drivers for success is a red herring. If end users have no choice, then yes, support from proprietary drivers is better then no support at all. But this is hardly a good situation.
The ultimate solution, the real solution, is that if you want to run Linux you should have hardware that is well supported by OSS drivers. This is real setup that makes Linux appealing.
Right now the only time you NEED to have proprietary drivers for Linux desktop is high-end 3d acceleration. That’s it.
For Wifi, for ACPI, motherboards, NIC cards, RAID drivers, etc etc etc. For almost any sort of hardware you want to use there exists good and high quality hardware with OSS support. But for 3D the only choices for high-end graphics are ATI and Nvidai, and they both refuse to support Linux with OSS drivers.
(for regular 3D graphics, for beryl/compiz and simple games then onboard Intel will work acceptively and it has OSS drivers)
Having userspace API isn’t going to help that any.
Realy, this API is designed for embedded developers anyways. It has very little to do with proprietary drivers. In fact it has not much to do with it at all. There is certain times with embedded development were userspace drivers is require for stability, control, and certain performance reasons. It does not matter at all if the source code is closed or open, there are technical reasons why you want userspace.
If you don’t beleive me.. then understand this:
In Linux, video drivers are ALREADY USERSPACE DRIVERS. Right now Video cards, for both 2D and 3D performance in X Windows are userspace drivers. They’ve always have been, and probably always will be.
Suprised?
Using the DRI/X/Linux driver model it works like this… I’ll use Intel drivers for a example.
Then xf86-video-intel video drivers is the 2-D X driver. It’s file is i915_drv.so and is provided by your X.org release. It’s completely userspace and newer versions support both XAA and EXA acceleration models.
The i915_dri.so file provides for 3D acceleration. They call it the ‘DRI driver’. DRI drivers are based on the open source Mesa OpenGL stack.. they take Mesa, accelerate what they can on the video card, and do the rest with software rendering. (OpenGL is a huge API, no video card accelerates all of it, only the portions that matter to performance in games and applications)
Now, having closed source drivers for those poses no legal problem at all. X.org and Mesa licenses allow for their use in proprietary software.
The only portion of the driver that needs to be in the kernel is called the DRM driver. This driver is what allows those userspace drivers to access the hardware and get their acceleration. It’s kept to a more-or-less minimum.
So the Linux driver model for video cards do allow for userspace drivers.
And guess what?
ATI’s driver still sucks and still is hugely complicated to install. It’s a total crap shoot if it works or not… And Nvidia still refuses to fix bugs and problems, some of them that cause crashes and security issues, because these problems are only noticed by a minority of users. And in both cases those companies still shovel large amounts of buggy, closed source code into your kernel were it can cause all sorts of problems from kernel panics to FS corruption (if your very unlucky).
So don’t think that userspace drivers are going to solve anything….
July 22nd, 2007 at 11:38
> In Linux, video drivers are ALREADY USERSPACE DRIVERS.
> Right now Video cards, for both 2D and 3D performance in X > Windows are userspace drivers. They’ve always have been,
> and probably always will be.
>
> Suprised?
>
> Using the DRI/X/Linux driver model it works like this… I’ll use
> Intel drivers for a example.
The NVIDIA drivers are not userspace drivers, part of them runs in userspace, but a _huge_ part runs in the kernel. Certainly _not_ only a DRI driver.
And I vaguely remember having to load a fglrx.ko module for some friends of mine using ATI cards, so I assume it’s the same for ATI.
July 22nd, 2007 at 12:55
Yes, exactly my point.
The XGI company makes a proprietary driver for Linux. They have open source DRM driver for the kernel, open source 2-D driver, and a closed source DRI driver (due to code obtained from another company).
Nvidia and ATI have always had the option of doing userspace video drivers, but they don’t. Do you know why? I don’t. There isn’t any sort of performance advantage to having kernel code for these sort of hardware.
They do it because they feel like it, I guess. It’s certainly much more likely to cause a crash and corrupt data the way they are doing it now. This is why Microsoft has moved from in-kernel video drivers to userspace video drivers for Vista.
The open source video drivers for X Windows have always been mostly userspace. In Linux, lots of USB drivers are userspace. Also, via fuse, you have file systems that are userspace.
Having drivers in userspace, with a fairly stable API, is nothing realy remarkable. _This_ paticular patch, for making generic API for embedded developers, is rather new, but userspace driver concept for Linux isn’t. For drivers that are in the kernel, there is a very good reason for it.
Once the hardware manufacturers and open source driver developers get together and work together then that produces the highest quality driver possible. Better then Windows or any sort of proprietary driver for Linux, generally. This is what is most desirable and is what everybody needs to aim for.
For selecting hardware, unless your realy a Linux geek, the best thing you can do is simply purchase a laptop or desktop from some place like System76 or Dell that already has all of it’s hardware supported by OSS drivers and pre-installs Linux. The only thing that remains closed source, is those nvidia drivers, because for high performance 3d Nvidia is the only game in town. (for normal 3d desktop and such Intel onboard works fine and is supported by OSS) That and the modem driver in Dell’s laptops is closed source for whatever reason, but most people don’t realy care about that.
This way it will ‘Just Work’. Just like when you go to a Apple store and buy a Apple computer all you have to do is open the box and plug it in.
July 22nd, 2007 at 13:12
It’s funny that Microsoft have moved the video driver from the kernel space to the userspace, given that it was a design decision to do this early on in the days of Windows 2000.
July 22nd, 2007 at 13:13
nate, about the proprietary video drivers:
For them building upon Mesa was not an option at all. Mesa was outdated and several years behind development for quite some time therefore relying on Mesa would have been crazy.
So they used their own OpenGL implementation - and this was closed.
July 22nd, 2007 at 13:32
“”It’s funny that Microsoft have moved the video driver from the kernel space to the userspace, given that it was a design decision to do this early on in the days of Windows 2000.”"
For some drivers, yes. For video drivers, no.
Video drivers as of XP were in-kernel. In fact it’s pre-Windows 2000. The desire for userspace drivers comes from earlier versions of NT. In fact very early of versions NT was a real Microkernel, but Microsoft dropped that when they realised that microkernels and high performance are two things that will never meet.
For Vista WDDM is the new driver model.
“”nate, about the proprietary video drivers:
For them building upon Mesa was not an option at all. Mesa was outdated and several years behind development for quite some time therefore relying on Mesa would have been crazy.
So they used their own OpenGL implementation - and this was closed.”"
That’s completely irrelevent to anything I said.
My point is that for video drivers in Linux, which (for modern high-end 3d) is the only major class of hardware were you can’t find good OSS drivers for, it’s always been possible for Nvidia and ATI to do the vast majority of the driver in userspace. Which they do not; they put a lot of code in the kernel. Whose OpenGL stack they choose to use is pretty much irrelevent to this.
Having this API for userspace drivers isn’t going to accomplish anything in terms of making Linux easier for end users, besides a small amount of embedded developers. For them there is certain classes of hardware and tasks were userspace drivers are technically desirable. Licensing isn’t realy a issue. If licensing or ’stable api’ or anything like that was the issue, then this patch wouldn’t exist.
July 22nd, 2007 at 13:49
Sorry I don’t want to be a hard-ass or anything. I understand what your saying and such. I want to be friends.
I’ll try another way to say it…
Userspace drivers aren’t going to make Linux any easier for folks because..
* Closed source drivers are, generally, technically inferior to OSS drivers with all else being equal. For Linux to be the most successfull it can be requires openess on the part of the drivers and hardware manufacturers supporting Linux.
* For graphical drivers, it’s always been possible to do most of it in userspace. (closed vs open doesn’t mater for this). XGI has closed source 3d graphics driver for Linux and it’s userspace. Nvidia and ATI could do much more of their drivers in userspace, but they do not. This patch isn’t going to affect them one way or another.
* For this patch in paticular it’s designed for specific circumstances that don’t apply much to desktop anyways.
* For the most part OSS drivers, weither in or out of the kernel, exist for almost all classes of hardware besides high end 3D graphics. Weither wifi, sata, sound, or anything else you can always find good and modern hardware with decent OSS drivers.
They are all seperate points. I am sorry for not being clearer with them before, but communication through writing is not my strong point. I’ll leave this blog alone now.
And on a side note; for the most part the simple act of installing a OS, any OS, on random hardware is a singificant enough a barrier to prevent Linux adoption on the desktop. The real answer is to have Linux pre-installed and supported on the OEM level, then it will have much more of a chance for higher popularity.
July 22nd, 2007 at 14:23
Ok, I lied. Almost.
This post on LKML will help to illistrate the point behind this paticular patch:
http://lkml.org/lkml/2007/7/19/557
So far it’s only for industrial I/O cards. Very simple devices, often only a few made, just flipping switches. Nothing like your typical consumer device that is hugely complicated and requires lots of other things in the kernel to work properly.
July 22nd, 2007 at 18:13
[…] of course - from what i understand (under Linux) device driver modules slot into the kernel. Well, no longer. The connection between both is being partially […]
July 22nd, 2007 at 18:27
nate: don’t worry, I don’t take such things personal. I’m just a bit surprised because it looks like you read my post like I would expect things massively to change now.
But I don’t. I’m very well aware that this API is mainly for embedded. And that userspace drivers have been possible before.
So thanks for the detailed comments.
July 22nd, 2007 at 18:50
nate,
Having a small well-defined interface for userspace drivers will make it very easy to snoop on the driver’s interaction with kernel space and easier to reverse-engineer in the long run.
July 22nd, 2007 at 20:21
[…] que no podrá usarse para drivers como los de las tarjetas gráficas. Noticia original en inglés: liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stable-useietiquetas: linux, api, drivers, kernel sin comentariosen: tecnología, software libre negativos: 0 […]
July 22nd, 2007 at 22:18
[…] read more | digg story 尼古拉 @ 2:17 pm [filed under Digg […]
July 22nd, 2007 at 23:44
@nate:
I can’t believe you wrote an entire essay to reply to a comment. You have too much time on your hands.
July 23rd, 2007 at 0:45
Listen and learn …
The pros –technical and in terms of reliability– of implementing drivers in user space are covered in http://en.sevenload.com/videos/DqzIRi2/Andrew-Tanenbaum-Design-of-microkernel-OS
As whether they should be binary, of course not! … for various reasons including for reliability –for those of you that are pragmatists– and security –for those of that are paranoid. Not that this thinning out of linux will not help facilitating the easy development of binary drivers and that this might help consolidate, promote, and gain corporate popularity for linux.
July 23rd, 2007 at 0:58
[…] Linux kernel 2.6.23 to have stable userspace driver API [image] Linus Torvalds included patches into the mainline tree which implement a stable userspace driver API into the […] […]
July 23rd, 2007 at 1:12
[…] /home/liquidat Linux kernel 2.6.23 to have stable userspace driver API « 23 07 2007 /home/liquidat Linux kernel 2.6.23 to have stable userspace driver API « […]
July 23rd, 2007 at 4:59
[…] na minha opinião mais um importante passo foi dado em direção a esse […]