Hybrid kernel

From Wikipedia, the free encyclopedia

 This article has been nominated to be checked for its neutrality.
Discussion of this nomination can be found on the talk page. (April 2008)
Graphical overview of a hybrid kernel
Graphical overview of a hybrid kernel

Hybrid kernel is a kernel architecture based on combining aspects of microkernel and monolithic kernel architectures used in computer operating systems. The category is controversial due to the similarity to monolithic kernel; the term has been dismissed by some as just marketing. The usually accepted categories are monolithic kernels and microkernels (with nanokernels and exokernels seen as more extreme versions of microkernels).

The idea behind this quasi-category is to have a kernel structure similar to a microkernel, but implemented as a monolithic kernel. In contrast to a microkernel, all (or nearly all) services are in kernel space. As in a monolithic kernel, there is no performance overhead associated with microkernel message passing and context switching between kernel and user mode. Also, as with monolithic kernels, there are none of the benefits of having services in user space.

Contents

[edit] Controversy

As mentioned above, a hybrid kernel is like a monolithic kernel in that there is no performance overhead associated with microkernel and there are none of the benefits of having services in user space.

That leads to the controversy - does having a microkernel-like structure in a monolithic kernel make such a distinct difference that another category of kernels is needed?

[edit] Proponents

Microsoft normally uses the term "microkernel" and sometimes "modified microkernel", "modified microkernel or macrokernel"[1] when describing the kernel part of the architecture of the Windows NT operating system line. The whole architecture is said to be composed of a "modified microkernel", drivers, Executive, and HAL, and GDI/GDI+ all in kernel space. There are user space APIs supporting different OS environments.

[edit] Opponents

Many operating systems and kernel experts have dismissed the label as meaningless, and just marketing:

Linus Torvalds said of this issue: "As to the whole 'hybrid kernel' thing - it's just marketing. It's 'oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has'."[2]

Sonny Rao of the IBM LTC Kernel Performance File/IO team said: "It's wrong...I think this talk ... was born from some kind of half-assed marketing game to try and make XXX kernel seem 'more advanced.' 'Micro' and 'hybrid' are always better/more advanced than 'Monolithic' right??"[3]

[edit] Hybrid kernel examples

[edit] NT kernel

The Windows NT operating system family's architecture consists of two layers (user mode and kernel mode), with many different modules within both of these layers.
The Windows NT operating system family's architecture consists of two layers (user mode and kernel mode), with many different modules within both of these layers.

The best known example of a hybrid kernel is the NT kernel inside Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. NT-based Windows is classified as a hybrid kernel (or a macrokernel[1]) rather than a monolithic kernel because the emulation subsystems run in user-mode server processes, rather than in kernel mode as on a monolithic kernel, and further because of the large number of design goals which resemble design goals of Mach (in particular the separation of OS personalities from a general kernel design). Conversely, the reason NT is not a microkernel system is because most of the system components run in the same address space as the kernel, as would be the case with a monolithic design (in a traditional monolithic design, there would not be a microkernel per se, but the kernel would implement broadly similar functionality to NT's microkernel and kernel-mode subsystems).

[edit] Description

The Windows NT design included many of the same objectives as Mach, the archetypal microkernel system, one of the most important being its structure as a collection of modules which communicate via well-known interfaces, with a small microkernel limited to core functions such as first-level interrupt handling, thread scheduling and synchronization primitives. This allows for the possibility of using either direct procedure calls or interprocess communication (IPC) to communicate between modules, and hence for the potential location of modules in different address spaces (for example in either kernel space or server processes). Other design goals shared with Mach included support for diverse architectures, a kernel with abstractions general enough to allow multiple operating system personalities to be implemented on top of it and an object-oriented organisation.[5][1]

The reason NT is not a microkernel system is that nearly all of the subsystems providing system services, including the entire Executive, run in kernel mode (in the same address space as the microkernel itself), rather than in user-mode server processes, as would be the case with a microkernel design. This is an attribute NT shares with early versions of Mach, as well as all commercial systems based on Mach, and stems from the superior performance offered by using direct procedure calls in a single memory space, rather than IPC, for communication amongst subsystems.

In describing NT, the list of which subsystems do not run in kernel mode is far shorter than the list of those that do. The user-mode subsystems on NT include one or more emulation subsystems, each of which provides an operating system personality to applications, the Session Manager Subsystem (smss.exe), which starts the emulation subsystems during system startup and the Local Security Authority Subsystem Service (lsass.exe), which enforces security on the system. The subsystems are not written to a particular OS personality, but rather to the native NT API (or Native API).

The primary operating system personality on Windows is the Windows API, which is always present. The emulation subsystem which implements the Windows personality is called the Client/Server Runtime Subsystem (csrss.exe). On versions of NT prior to 4.0, this subsystem process also contained the window manager, graphics device interface and graphics device drivers. For performance reasons, however, in version 4.0 and later, these modules (which are often implemented in user mode even on monolithic systems, especially those designed without internal graphics support) run as a kernel-mode subsystem.[1]

As of 2007, one other operating system personality, UNIX, is offered as an optionally installed system component on certain versions of Windows Vista and Windows Server 2003 R2. The associated subsystem process is the Subsystem for UNIX-Based Applications (psxss.exe), which was formerly part of a Windows add-on called Windows Services for Unix. An OS/2 subsystem (os2ss.exe) was supported in older versions of Windows NT, as was a very limited POSIX subsystem (psxss.exe). The POSIX subsystem was supplanted by the UNIX subsystem, hence the identical executable name.[6]

Applications that run on NT are written to one of the OS personalities, and not to the native NT API, which is largely undocumented (with the exception of routines used in device driver development). An OS personality is implemented via a set of user-mode DLLs (see Dynamic-link library), which are mapped into application processes' address spaces as required, together with an emulation subsystem server process (as described previously). Applications access system services by calling into the OS personality DLLs mapped into their address spaces, which in turn call into the NT run-time library (ntdll.dll), also mapped into the process address space. The NT run-time library services these requests by trapping into kernel mode to either call kernel-mode Executive routines or make Local Procedure Calls (LPCs) to the appropriate user-mode subsystem server processes, which in turn use the NT API to communicate with application processes, the kernel-mode subsystems and each other.[6]

[edit] Plan 9 kernel

[edit] Description

One of the main design goals is to represent all resources as files and use a single communication protocol for both local and remote resources. The Plan 9 kernel uses both in-kernel (kernel mode) but more commonly user mode servers. Communication with user mode servers - fileservers - uses 9P. Kernel mode examples are device drivers and network interfaces (ethernet). Examples of user mode are networking (IP stack), environment, mailboxes, serial-console multiplexor, spam filter, CD interpreter, foreign filesystems and tapes, backup system, window system, and /proc [7].

[edit] Classification

Due to the extensive use of user mode fileservers together with some in-kernel systems, this is a simpler candidate for inclusion as a hybrid kernel.

[edit] See also

[edit] Notes

  1. ^ a b c d MS Windows NT Kernel-mode User and GDI White Paper. Microsoft Corporation (2007). Retrieved on 2007-03-01.
  2. ^ Linus Torvalds, Real World Technologies Discussion Forum (2006-05-09)
  3. ^ Sonny Rao, Real World Technologies Discussion Forum (2006-05-08)
  4. ^ An Overview of the NetWare Operating System(2007-02-07)
  5. ^ Silberschatz, Abraham; Peter Baer Galvin and Greg Gagne (2005). Operating System Concepts; 7th Edition. Hoboken, New Jersey: John Wiley & Sons Inc. ISBN 978-0-471-69466-3. 
  6. ^ a b Probert, Dave (2005). Overview of Windows Architecture. Using Projects Based on Internal NT APIs to Teach OS Principles. Microsoft Research/Asia - Beijing. Retrieved on 2007-03-01.
  7. ^ Why Plan 9 matters, Geoff Collyer (2006-09-12)

[edit] References

v • d • e
Operating system
Kernel
Process management
Memory management
Examples
Miscellaneous concepts