2016년 5월 12일 목요일

Microkernel

Microkernel

Constitution of the OS of a monolithic kernel and the microkernel
Conception diagram of the microkernel

The microkernel (British: microkernel) is the name of the kernel part of design thought of the operating system and such OS. A way of thinking that I leave only a minimum in the kernel space among various functions that the OS takes and can simplify an overall design by moving the remainder to the user level, and, as a result, the performance can improve. Because the kernel body is limited to a small function, I am called "microkernel", but may not necessarily constitute the small OS.

With an appearance of the microkernel, I came to call the conventional OS "a monolithic kernel" (will called the kernel of the monolith).

Table of contents

Characteristic

At first I limit a function offered in kernel space to virtualization, process control, interprocess communication of the memory space and, in the pure microkernel, map the interrupts with respect for all communication. On top of that, I implement an associate kernel function such as file system and the device driver as those application and operate it in user space. A plural number operates those function sets by the unit called the server in some cases.

The merit of having such a form,

  • Improvement (I can perform Extensions, debugging easily) of the OS development efficiency
  • I can update the OS except the kernel without stopping the whole system
  • It becomes easy to build the OS specialized in application to provide only a necessary function

などである. In addition, it is advantageous to use of large-scale resources because generally the abstract degree of resources is high in the microkernel and can implement multiprocessor correspondence and communication of the network transmission naturally.

On the other hand, several-fold loss may appear from several percent when the overhead of function aspect each other is big and implements the function that is equal to a monolithic kernel to use interprocess communication at every place. (co-location) which I move a necessary function to the kernel space to avoid in particular the cost of the context switch and may operate like a monolithic kernel in an appearance.

History

The kernel of the early OS was relatively small partly because the memory capacity of the computer was small. As the ability of the computer grew up, the number of devices which a kernel must control increased. Still generally it was small even if, for example, the kernel of the original UNIX included device driver and file system. When address space spread to 32 bits from 16 bits, a kernel design ceased to be restricted by the hardware architecture, and the growth of the kernel began.

It is Berkeley Software Distribution to have become the beginning of the enlargement of the UNIX kernel (BSD). In addition to the role of the previous OS, I add plural file system by the BSD and include complete TCP/IP protocol stack, and various imagination devices which can work, and do an existing program on a network are added. I succeeded in a compact and high-performance OS design by the UNIX standardizing a resource in the concept called the file, and letting you joined a small process to treat a file together with a pipe and communicate mutually. However, with a change of the later use environment, resources not to be able to necessarily treat as a file increase. For example, the network communication is carried out in the concept called the socket, but the socket is not a file. As a result, it may be said that a situation that I am similar in a postscript, and the cord named the fault lets the OS enlarge occurred. Such a growth continued for years, and the source code of the kernel was enlarged in millions of lines. As a result, the possibility that a bug was underlying increased, and difficulty of the maintenance increased.

The microkernel begins in the point of view called such a "re-design of the UNIX". It was said that the microkernel design facilitated the management of the cord theoretically by cutting and bringing down the service group that was a part of the kernel between the user sky. In addition, it was thought that security and stability rose by reducing the quantity of the cord which worked by kernel mode. For example, it can continue functioning for the whole system because the microkernel is not affected even if network service crashes by buffer overrun.

The direct problems of the thing consisting of the cords that there are many OS's,

  • A memory area (footprint of the kernel space) that kernel in itself occupies grows big
  • It is disadvantageous to transplant characteristics and maintenance

といったものである. Furthermore, the implementation that I did not assume at the time of UNIX development such as multiprocessor and the virtual memory with the increase of calculator resources appeared, and it was thought that the refinement of the OS concept including them was necessary.

Therefore it is microkernel that I take "large-scale resources" and "high-speed communication" into consideration, and reached the development idea of the UNIX called "the cooperation movement by the process to communicate mutually". I was as a central concept with a file in the UNIX, but I put the principal objective into a process and communication in the microkernel, and every resource such as interrupt and I/O is abstracted thoroughly.

The microkernel developed in such a background in the 1980s was accompanied by some trials to let an existing built-in kernel fit a new system. With enormous work, careful cord management was required to develop device driver, a protocol stack, file system and other low-level systems included in a conventional kernel newly at a time. The service implemented as a program of the user space works like a normal user's program. Therefore not only handling of those services became easy, but also can optimize the left kernel part without minding a side effect. Furthermore, I could build the totally new OS on the common core region if I said and contributed to an OS study.

In addition, the reuse of the calculator resources which became old then was considered. In other words, it is a way of thinking that I connect it on the network even if it is an old system and can utilize as resources if transplant characteristics use the compact OS highly.

Early Local Area Network comes up in the 1980s, and the microkernel is very promising; was said technically. If it employs mechanism to scatter the functions of the kernel in the user space, this is because it can scatter systems on the network. The early microkernel such as Mach was proved to have a problem with performance, but considered that an advantage was bigger than it and played a key role of the OS study until the end of 1990s. In implemented Mach, I really succeeded in reduction of the quantity of original expected cord. An abstract degree is high, and the good microkernel with possibility is proper for a trend and is considered to be the thing which will be promising in the future at this time. However, the performance of the computer improved markedly in comparison with network performance in the meantime and was not able to ignore the issue of performance of the microkernel in consideration of an advantage of the ease of the development either. Various trials that performance improved an existing system were accomplished, but overheads always became the problem, and it was necessary to return the server which became the program of the user space to the kernel for the performance enhancement. It was not talked about the large-scale trial such as Mach by 2000, but the Mach kernel upgraded version called XNU which OPENSTEP adopted is adopted in Darwin and OS X [1]. As of 2012, Mach-based GNU Hurd functions, and Arch Linux and the test copy of Debian which adopted it are moving.

The large-scale study of the microkernel burnt down, but was able to continue researching and developing it. Most of issue of performance in the early microkernel design came to be considered to have been caused by the desire of the designer to want to implement services as many as possible by the system of the single use not the thing by the basic requirements of the concept. I used the assembly code and I depended on the architecture of the processor and usually did that I supported it by software and adopted a more practical approach to a problem, and the microkernel that performance was improved dramatically came to appear. The name called nanokernel (nanokernel) was used to distinguish such a new generation microkernel from the implementation including conventional many system services. However, I am not called the nanokernel when the shifts from conventional microkernel to a nanokernel are almost completed.

As a method in conjunction with microkernel and the closeness with エクソカーネル (English version) [2]. エクソカーネル has many a hyper visor and common points [3], but I do not insist on the very small nature and am specialized in virtual machine support. Actually, the L4 microkernel is used for the implementation of the hyper visor well.

Interprocess communication

Interprocess communication (IPC) is some kind of mechanism to enable the communication between processes, and the message transmission is used well. The shared memory is a kind of the interprocess communication mechanism closely, too, but, speaking of IPC, points to the message in microkernel generally. By IPC, I can build the OS by some small programs called the server and can call a server from others using IPC. I can implement the support of neighboring hardware like that, too, and there are device driver, a protocol stack, the file system of the network, various things including the graphics to the server.

There are an expression and the ceremony of async in IPC in the same period. Async IPC is similar to network communication. The transmission side publishes a message and continues processing. It is notified of whether the reception side checks the arrival of the message regularly by some kind of detection mechanism. A kernel manages a buffer and the cue for the message in async IPC, and a kernel handles the buffer overflow. In addition, two times of messages are copied (from the transmission side from a kernel and a kernel the reception side). In synchronization IPC, the transmission side or the reception side is blocked until another becomes the IPC possibility. The buffering is unnecessary for the multiple copy, too, but needs adroitness for programming because it is necessary for both to meet explicitly. Many programmers like the reception in the async transmission and the same period.

The first generation microkernel supported both synchronization IPC and async IPC generally, but the performance was bad. Jochen Liedtke showed that there was the cause for design and implementation of the IPC mechanism. He made IPC cost a one-tenth or less in L4 microkernel [4]. In IPC, both the transmission and the reception are supported in system call and it is only a synchronization type and hands data as many as possible in registers. Furthermore, Liedtke introduced a concept called direct process switch and, in the case of IPC, performed a direct (incomplete) context switch from the transmission side to the reception side. Therefore, in L4, I can transfer the message in the register when I hand some or all of the message in register group without copying it really. Furthermore, I remove an overhead calling a scheduler. This is suitable for IPC when I call a server for RPC in particular. Another optimization includes a thing called lazy scheduling, and do not scan a scheduling cue in IPC; keep on having blocked a thread by a lady cue during IPC to need it. When a scheduler is called, I put such a thread into a suitable waiting queue.

Even if much communication is the ceremony of synchronization by the client server type system basically and used the primitive which is async, clients usually call servers and will wait for a reply. Because the implementation became effective, the one came to provide only synchronization IPC primitive in the microkernel after L4. Synchronization can implement async IPC on IPC primitive using a supporting thread. However, it becomes clear for asynchronous communication support with the commercial product which adopted L4 that notice of async mechanism is necessary and adds it. A system such as this signal is not a thing transferring data, and the buffering by the kernel is unnecessary.

Another is blocked until one side of the communication becomes able to reply in synchronization IPC. Therefore, a deadlock state occurs easily when I use IPC without any restriction. In addition, when prevent a client sending a demand, and a reply from meeting; easily such as the denial-of-service attack is in a condition. Therefore, you must provide means to prevent a block to cross for a long term in synchronization IPC. Much microkernel provides time-out for IPC summons and limit flying hours. The setting of the time-out time is difficult, and, as a result, the time-out of the client is unlimited and really often does the time-out of the server with zero. As a result, it did not allow you to set time-out time optionally, and it was in a tendency to prepare only for a flag to show whether you let you fail in IPC immediately when a partner could not reply. I will thereby select whether it is zero as time-out time, or it is unlimited. The recent version of L4 and Minix comes to look like it, too (I can set time-out time optionally in QNX and former L4).

Server

A server in the microkernel is something like daemon, but some servers are given the special privilege which can access a part of the physical memory space. A server of the device driver becomes able to thereby communicate with hardware directly.

A basic server in the general-purpose microkernel includes a file system server, a device driver server, a network server, a display server, the server of the user interface device. I almost cover the service that the monolithic kernel of the Unix system provides in these servers group. The required server starts at the time of a setup and starts service. The server works in environment like the user application, and the development is similar to application, too. The frequent build and reboot becoming necessary for kernel development are unnecessary.

Furthermore, even if a disorder occurs with a server, the whole system does not crash and should merely reboot the server. However, because a part of the system state may be lost because a disorder occurs with a server; as for the application side corresponding to the server obstacle it is necessary. 例えば、TCP/IP接続を担うサーバがあるとする。 このサーバを再起動すると、アプリケーションから見てコネクションが失われることになるが、これは通常のネットワークでも起き得る障害である。 しかしアプリケーションが障害発生を予期していないサービスの場合、アプリケーションのコードを修正する必要がある。 QNXではサーバの再起動への対応として QNX High Availability Toolkit が提供されている[5]。

全サーバを再起動可能にするため、トランザクションやレプリケーションやチェックポインティング（英語版）といったデータベース的技法を取り入れているマイクロカーネルもある。例えば ChorusOS があり、電気通信業界の高信頼アプリケーション用にそのような機能を備えている。

デバイスドライバ

Direct Memory Access (DMA) を頻繁に行うデバイスドライバは、カーネルのデータ構造を含めた物理メモリの任意の位置に書き込める必要がある。そのようなドライバは信頼されていなければならないが、必ずしもカーネル内に含まれている必要はない。実際、カーネルの一部だからといってデバイスドライバがより信頼できるというわけではない。

デバイスドライバをユーザー空間で動作させたとしても、ドライバが発生しうる障害のダメージが低減されることはないが、バグのあるドライバによってシステムの安定性が影響を受けにくくするという効果はある（悪意あるドライバの場合はその限りではない）。（デバイスではなく）ドライバのコード自体が不正なメモリアクセスを行う場合、メモリ管理ハードウェアが捉えることになる。さらにDMAを行わないデバイスでは、ユーザー空間で動作させることでドライバを信頼されないもの（特権が不要なもの）とすることができる。最近ではIOMMUを備えたコンピュータが増えており、IOMMUを使ってデバイスの物理メモリアクセスを制限できることが多い[6]。これもユーザーモードのドライバを信頼されないものとすることができる。

ユーザーモードのドライバは実際にはマイクロカーネルより古くから存在する。1967年の Michigan Terminal System (MTS) で初めて（ファイルシステムも含めた）ユーザー空間のドライバがサポートされた[7]。歴史的には、ドライバをカーネルに含めることはあまり問題とされなかった。周辺デバイスの数は少なく、特権が必須だったためであり、カーネルに含めることで性能問題を防いでいた。Unixもそのスタイルを踏襲し[8]、Linuxや Windows XP 以前のWindowsも同様だった。デバイスの種類が豊富になってくると、ドライバのコード量も増大するようになり、カーネル全体に占める割合も増えていった。

必須コンポーネントと極小性

マイクロカーネル上で任意のOSサービス群を構築しなければならない場合、マイクロカーネルはいくつかの中核機能を提供しなければならない。最小でも以下が含まれる。

このような最小設計は Per Brinch Hansen の Nucleus とIBMのVM（英語版）のハイパーバイザがさきがけである。そして、Liedtke の「極小原則」として次のように定式化された。

あるコンセプトがマイクロカーネル内で許容されるのは、それをカーネルの外に移したとき、すなわち競合実装が許容されるとき、システムに要求される機能の実装が妨げられる場合のみである。[9]

他のあらゆるものはユーザーモードのプログラムとして実装できるが、デバイスドライバをユーザープログラムとして実装する場合、一部のプロセッサアーキテクチャではI/Oハードウェアにアクセスするための特別な特権を必要とする。

極小原則とも関連しマイクロカーネル設計で重要な観点として機構と方針の分離があり、極小のカーネル上に任意のシステムを構築できるようにするのに必要である。方針をカーネル内で実装すると、ユーザーレベルでは上書きできず、マイクロカーネルの可能性が一般に制限される[2]。ユーザーレベルのサーバで実装された方針はサーバを置換することで（あるいは同様のサービスを提供する複数のサーバからアプリケーションが選択することで）変更できる。

効率化のため、ほとんどのマイクロカーネルはスケジューラとタイマー管理を含んでおり、極小原理と機構と方針の分離の原則に反している。

マイクロカーネルを使ったシステムの立ち上げ（ブート）では、カーネル内に含まれないデバイスドライバが必要になる。一般に必要なデバイスドライバをカーネルと共にパッケージ化してブートイメージを作成する必要があり、カーネルはデバイスドライバを配置して起動する手順をサポートしている必要がある。例えばL4ではそのようなブート方式になっている。一部のマイクロカーネルは重要なデバイスドライバを（極小原則に反して）カーネルに含めており、LynxOSや元々のMinixが挙げられる。ブートを単純化するため、ファイルシステムまでもカーネルに含める場合がある。マルチブート対応のブートローダからブートできるマイクロカーネルのシステムもある。その場合、静的リンクされたサーバ群をロードするか、OSイメージをマウントすることで立ち上げを続行する。

マイクロカーネルにおいては、IPCシステムと仮想記憶管理の設計が重要であり、ページフォールト処理やスワッピングをユーザーモードのサーバで安全に実装できるようにすることが肝要である。全サービスがユーザーモードのプログラムで実行されるので、それらプログラム間の効率的通信手段が必須である。これはモノリシックカーネルに比べて遥かに重要である。効率化するには、IPCシステムのオーバーヘッドを小さくするだけでなく、CPUスケジューリングともうまくやりとりしなければならない。

性能

多くの主流のプロセッサにおいて、サービスを得るのにかかるコストはモノリシックカーネルよりもマイクロカーネルの方が本質的に高い[2]。モノリシックなシステムでは、サービスを得るのに1回のシステムコールを使用し、その際に2回の「モード切り換え」（プロセッサのリングまたはCPUモードの変更）を必要とする。マイクロカーネルを採用したシステムでは、サービスを得るにはサーバにIPCメッセージを送り、別のIPCメッセージで結果を得る必要がある。このときドライバがプロセスとして実装されていればコンテキストスイッチが必要であり、プロシージャとして実装されていれば関数呼び出しが必要である。さらに実際にデータをサーバに渡して結果のデータを戻してもらうには、データをコピーするオーバヘッドが余分にかかる。モノリシックカーネルでは、クライアント（ユーザー空間）の持つバッファにあるデータに直接アクセス可能である。

したがってマイクロカーネルシステムには性能問題が潜在している。実際、MachやChorusOSといった第一世代のマイクロカーネルを採用したシステムの性能は低かった[10]。しかし Jochen Liedtke はMachの性能問題は設計と実装がまずかったためであることを示し、特にMachがページキャッシュ（英語版）を使いすぎていることを指摘した[9]。Liedtke は自身のL4マイクロカーネルを注意深く設計・実装することで、特に極小原則に従えばIPCコストをMachの10分の1以下にできることを証明した。L4のIPC性能は様々なアーキテクチャ上で最速を誇った[11][12][13]。

そういった結果により、第一世代のマイクロカーネルの性能の低さは第二世代のL4などのマイクロカーネルには当てはまらないことを示したが、マイクロカーネルをベースにしたシステムが高性能を発揮できることを証明したわけではなかった。それでもモノリシックなLinuxサーバをL4上に移植したものは、通常のLinuxに対して数パーセントのオーバーヘッドを示しただけだった[14]。しかし、単一サーバシステムはマイクロカーネルの利点を生かしているとは言い難く、OSの機能を複数のサーバに分離したときの性能が重要だとされた。

複数サーバの商用システムはいくつか存在しており、例えばリアルタイムオペレーティングシステムのQNXやIntegrity（英語版）がある。そういったシステムとモノリシックなシステムとの包括的性能比較は公表されたことがない。さらに言えばそれら商用システムでは性能が最重要課題ではないようで、割り込み応答時間の保証や頑健性のための単純さが強調されている。複数サーバの高性能OSを構築する試みとしてIBMの Sawmill Linux というプロジェクトがあった[15]。しかし、このプロジェクトは完了することなく中止された。

同じころ、ギガビット・イーサネットのような高速デバイスのデバイスドライバをユーザーレベルで実装したものが、カーネル内のデバイスドライバと同等の性能を発揮することが示されている[16]。これは複数サーバの高性能システムが構築可能であることを示唆している。

セキュリティ

マイクロカーネルはセキュリティ面で優れているとよく言われてきた[17][18]。セキュリティの観点では、マイクロカーネルの極小原則は、全てのコードについて必要とされる機能を提供するのに必要な権限だけを持つべきであるという最小権限の原則の直接的帰結である。極小性は、システムのトラステッド・コンピューティング・ベース（英語版） (TCB) を極小に保つべきであることを要求する。カーネル（ハードウェアの特権モードで実行されるコード）は常にTCBの一部であり、セキュリティ指向設計ではそれを極小化するのが自然である。

結果として、マイクロカーネル設計は高度なセキュリティを要求される用途で採用されており、例えばKeyKOS（英語版）、EROS（英語版）、軍用システムなどがある。実際、コモンクライテリア (CC) の最高保証レベル（評価保証レベル (EAL) 7）では、対象の評価が「単純」であること、複雑なシステムの真の信頼性を確立するのに実際的不可能性を確認できることを明示的に要求している。

第三世代

近年のマイクロカーネル研究開発は、カーネルAPIの形式仕様とそのAPIのセキュリティ属性の形式的証明に集中している。第一の例として、EROSでの隔離機構の数学的証明があり、EROS API を単純化したモデルに基づいている[19]。より最近の例として、L4のバージョンの一種である seL4 のプロテクションモデルについて自動検証された包括的な証明がなされている[20]。

それにより「第三世代マイクロカーネル」と呼ばれるものが生まれている[21]。これはセキュリティ指向のAPI、ケイパビリティによるリソースアクセス制御、最重要概念としての仮想化、カーネル資源管理への革新的アプローチ[22]、形式的分析に適した設計、などを特徴としつつ、性能向上を目標としたものである。例として、Coyotos（英語版）、seL4、Nova[23][24]、Fiasco.OC[23][25]などがある。

seL4の場合、実装についての完全な形式的検証がなされており[21]、形式仕様と実装が一致していることが数学的に証明されている。それにより、APIについて証明された属性が実際のカーネルでも保持されていることが保証でき、CC EAL7 をも越える保証の程度となっている。

ナノカーネル

ナノカーネル (nanokernel) またはピコカーネル (picokernel) という用語は歴史的には次のような意味で使われてきた。

  1. カーネルコードの量、すなわちハードウェアの特権モードで実行されるコードの量が極めて小さいカーネル。カーネルが極めて小さいことを強調する際に「ピコカーネル」という呼称も使われた。「ナノカーネル」という用語を生み出したのは Jonathan S. Shapiro で、The KeyKOS NanoKernel Architecture (1992) という論文で初めて使っている。それはMachへの冷笑的反応であった。彼はMachについて、本質的に非構造的であり、モノリシックであるのにマイクロカーネルと主張しているだけで、置き換えようとしているものより性能が悪いと評した。その用語が他でも使われ、さらにピコカーネルという呼称が生まれた背景には、従来のマイクロカーネルが「カーネルが小さい」という点から大きく外れていったことを示唆している。その後、ナノカーネルとピコカーネルはマイクロカーネルと同じ意味で使われるようになった。
  2. OSの下にある仮想化層。より正確には「ハイパーバイザ」と呼ばれる。
  3. カーネルの最下層部を形成している ハードウェア抽象化層。例えば Adeos があり、通常のOSにリアルタイム機能を提供するのに使われる。

また、小さくないカーネルをナノカーネルと呼ぶ用例も少なくとも1つあり、その場合はクロック間隔としてナノ秒単位までサポートしているカーネルを指す[26]。

脚注

  1. ^ "Porting UNIX/Linux Applications to Mac OS X". Apple. 2011年4月26日閲覧。
  2. ^ a b c Liedtke, Jochen (September 1996). "Towards Real Microkernels". Communications of the ACM 39 (9): 70–77. doi:10.1145/234215.234473. 
  3. ^ Heiser, Gernot; Uhlig, Volkmar and LeVasseur, Joshua (January 2006). "Are Virtual-Machine Monitors Microkernels Done Right?". ACM SIGOPS Operating Systems Review (ACM) 40 (1): 95–99. doi:10.1145/1113361.1113363. 
  4. ^ Liedtke, Jochen (December 1993). "Improving IPC by kernel design". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp. 175–88. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.1293 
  5. ^ QNX High Availability Toolkit
  6. ^ Wong, William (2007-04-27). "I/O, I/O, It's Off to Virtual Work We Go". Electronic Design. http://electronicdesign.com/article/embedded/i-o-i-o-it-s-off-to-virtual-work-we-go15350 2009年6月8日閲覧。. 
  7. ^ Alexander, Michael T. (1971). "Organization and Features of the Michigan Terminal System". Proceedings of the November 16–18, 1971, fall joint computer conference 40: 589–591. doi:10.1145/1478873.1478951. 
  8. ^ Lions, John (1977-08-01). Lions' Commentary on UNIX 6th Edition, with Source Code. Peer-To-Peer Communications. ISBN 978-1-57398-013-5. 
  9. ^ a b Liedtke, Jochen (December 1995). "On µ-Kernel Construction". 15th ACM symposium on Operating Systems Principles. pp. 237–250. doi:10.1145/224056.224075 
  10. ^ Chen, Bradley; Bershad, Brian (December 1993). "The Impact of Operating System Structure on Memory System Performance". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp. 120–33. doi:10.1145/168619.168629 
  11. ^ Liedtke, Jochen; Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; Heiser, Gernot; Islam, Nayeem; Jaeger, Trent (May 1997). "Achieved IPC performance (still the foundation for extensibility)". 6th Workshop on Hot Topics in Operating Systems. Cape Cod, MA, USA: IEEE. pp. 28–31. http://os.ibds.kit.edu/65_987.php 
  12. ^ Gray, Charles; Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot (April 2005). "Itanium—a system implementor's tale". USENIX Annual Technical Conference. Annaheim, CA, USA. pp. 264–278. http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html 
  13. ^ van Schaik, Carl; Heiser, Gernot (January 2007). "High-performance microkernels and virtualisation on ARM and segmented architectures". 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. pp. 11–21. http://www.ssrg.nicta.com.au/publications/papers/vanSchaik_Heiser_07.pdf 2007年4月1日閲覧。 
  14. ^ Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian (October 1997). "The performance of µ-kernel-based systems". Proceedings of the sixteenth ACM symposium on Operating systems principles: 66–77. doi:10.1145/268998.266660. ISBN 0-89791-916-5. http://portal.acm.org/citation.cfm?id=266660&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618. 
  15. ^ Gefflaut, Alain; Jaeger, Trent; Park, Yoonho; Liedtke, Jochen; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; Reuther, Lars (2000). "The Sawmill multiserver approach". 9th ACM SIGOPS European Worshop. Kolding, Denmark. pp. 109–114 
  16. ^ Leslie, Ben; Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; Heiser, Gernot (September 2005). "User-level device drivers: achieved performance". Journal of Computer Science and Technology 20 (5): 654–664. doi:10.1007/s11390-005-0654-4. 
  17. ^ Tanenbaum, Andrew S., Tanenbaum-Torvalds debate, part II
  18. ^ Tanenbaum, A., Herder, J. and Bos, H. (May 2006).
  19. ^ Shapiro, Jonathan S.; Weber, Samuel. "Verifying the EROS Confinement Mechanism". IEEE Conference on Security and Privacy. http://www.eros-os.org/papers/oakland2000.ps 
  20. ^ Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007). Verified Protection Model of the seL4 Microkernel. submitted for publication. http://www.nicta.com.au/pub?doc=1474. 
  21. ^ a b Klein, Gerwin; Elphinstone, Kevin; Heiser, Gernot; Andronick, June; Cock, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon (October 2009). "seL4: Formal verification of an OS kernel". 22nd ACM Symposium on Operating System Principles. Big Sky, MT, USA. http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf 
  22. ^ Elkaduwe, Dhammika; Derrin, Philip; Elphinstone, Kevin (April 2008). "Kernel design for isolation and assurance of physical memory". 1st Workshop on Isolation and Integration in Embedded Systems. Glasgow, UK. doi:10.1145/1435458. http://ertos.nicta.com.au/publications/papers/Elkaduwe_DE_08.abstract 
  23. ^ a b "TUD Home: Operating Systems: Research: Microkernel & Hypervisor". Faculty of Computer Science. Technische Universität Dresden (2010年8月12日). 2011年11月5日閲覧。
  24. ^ Steinberg, Udo; Kauer, Bernhard (April 2010). "NOVA: A Microhypervisor-Based Secure Virtualization Architecture". Eurosys 2010. Paris, France. pp. 209–222. http://doi.acm.org/10.1145/1755913.1755935 
  25. ^ Lackorzynski, Adam; Warg, Alexander (March 2009). "Taming Subsystems - Capabilities as Universal Resource Access Control in L4". IIES'09: Second Workshop on Isolation and Integration in Embedded Systems. Nuremberg, Germany. http://portal.acm.org/citation.cfm?id=1519135&dl=ACM 
  26. ^ http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf

参考文献

「https://ja.wikipedia.org/w/index.php?title=マイクロカーネル&oldid=58436538」から取得

This article is taken from the Japanese Wikipedia Microkernel

This article is distributed by cc-by-sa or GFDL license in accordance with the provisions of Wikipedia.

Wikipedia and Tranpedia does not guarantee the accuracy of this document. See our disclaimer for more information.

In addition, Tranpedia is simply not responsible for any show is only by translating the writings of foreign licenses that are compatible with CC-BY-SA license information.

0 개의 댓글:

댓글 쓰기

피드 구독하기: 댓글 (Atom)