Lompat ke isi

Mikrokernel: Perbedaan antara revisi

Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
Jelajahi riwayat secara interaktif
Konten dihapus Konten ditambahkan
VisualTeks wiki
Jazle (bicara | kontrib)
3.442 suntingan
Rintisan awal mikrokernel
 
InternetArchiveBot (bicara | kontrib)
Bot
668.869 suntingan
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.2
 
(43 revisi perantara oleh 24 pengguna tidak ditampilkan)
Baris 1: Baris 1:
[[Berkas:OS-structure.svg|jmpl|450px|Stuktur sistem operasi berbasis mikrokernel monolitik]]
{{terjemah|Inggris}}
Dalam pengetahuan [[Ilmu Komputer]], '''mikrokernel''' merupakan seperangkat [[perangkat lunak]] dalam jumlah minimum yang meyediakan beragam mekanisme dasar yang dibutuhkan untuk bekerja sebagai sebuah [[Sistem Operasi|sistem operasi]], seperti halnya manajemen pengalamatan ruang tingkat rendah, manajemen [[thread]], dan [[Interprocess Communication|komunikasi antar proses]]. Dalam implementasinya mikrokernel merupakan satu-satunya perangkat lunak yang berjalan dengan tingkat kewenangan tertinggi (umumnya disebut sebagai modus supervisor atau modus kernel) dari serangkaian level kewenangan yang tersedia pada perangkat kerasnya. Layanan yang disediakan oleh sebuah sistem operasi beberapa diantaranya adalah [[device driver]], protokol jaringan, [[sistem berkas]], dan kode [[antarmuka pengguna]] yang berada dalam ruang pengguna.
[[Image:OS-structure.svg|thumb|450px|Structure of monolithic and microkernel-based operating systems, respectively]]
Dalam pengetahuan [[Ilmu Komputer]], mikrokernel merupakan modul inti yang meyediakan beragam mekanisme yang dibutuhkan untuk mengembangkan sebuah [[Sistem Operasi|sistem operasi]], seperti halnya manajemen pengalamatan ruang tingkat rendah, manajemen [[thread]], dan [[Interprocess Communication|komunikasi antar proses]]. Dalam implementasinya mikrokernel merupakan satu-satunya perangkat lunak yang berjalan dengan tingkat kewenangan tertinggi (umumnya disebut sebagai mode supervisor atau mode kernel) dari serangkaian level kewenangan yang tersedia pada perangkat kerasnya. Layanan yang disediakan oleh sebuah sistem operasi beberapa diantaranya adalah [[device driver]], [[protocol stack]], [[Sistem berkas]], dan kode [[antarmuka pengguna]] yang berada dalam [[Ruang pengguna]].


Mikrokernel sangat erat terkait dengan [[exokernel]]<ref name="Liedtke_96">{{cite journal
Mikrokernel sangat erat terkait dengan exokernel<ref name="Liedtke_96">{{cite journal
| last = Liedtke
| last = Liedtke
| first = Jochen
| first = Jochen
Baris 12: Baris 11:
| volume = 39
| volume = 39
| issue = 9
| issue = 9
| pages = 70&ndash;77
| pages = 70–77
| issn =
| issn =
| pmid =
| pmid =
Baris 25: Baris 24:
| laydate =
| laydate =
| quote =
| quote =
}}</ref>
}}</ref>
, serta memiliki banyak kesamaan dengan [[hypervisor]].<ref name="Heiser_UL_06">{{cite journal
, serta memiliki banyak kesamaan dengan hypervisor.<ref name="Heiser_UL_06">{{cite journal
| title=Are Virtual-Machine Monitors Microkernels Done Right?
| title=Are Virtual-Machine Monitors Microkernels Done Right?
| author=[[Gernot Heiser|Heiser, Gernot]]; Uhlig, Volkmar and LeVasseur, Joshua
| author=[[Gernot Heiser|Heiser, Gernot]]; Uhlig, Volkmar and LeVasseur, Joshua
Baris 33: Baris 32:
| issue=1
| issue=1
| pages=95–99
| pages=95–99
| month=January
| month=January
| year=2006
| year=2006
| url=http://l4ka.org/publications/2006/p95-heiser.pdf
| url=http://l4ka.org/publications/2006/p95-heiser.pdf
| publisher=ACM
| publisher=ACM
| doi = 10.1145/1113361.1113363 <!--Retrieved from CrossRef by DOI bot-->
| doi=10.1145/1113361.1113363 <!--Retrieved from CrossRef by DOI bot-->
| format=PDF}}</ref>
| format=PDF
| access-date=2009-03-23
namun implementasinya lebih bersifat minimalis, dan secara spesifik untuk mendukung pengimplementasian [[Mesin virtual]]. [[L4 microkernel]] sering juga disebut sebagai hypervisor, yang mengindikasikan kemungkinan pengimplementasian sebuah mikrokernel sebagai hypervisor. Istilah [[Nanokernel|nanokernel]] dalam sejarahnya digunakan untuk membedakan mikrokernel saat ini dengan istilah mikrokernel sebelumnya yang menyediakan layanan sistem aktual, namun secara prinsip minimalitas menurut [[Jochen Liedtke]] dalam desain [[L4 microkernel]] menyebutkan bahwa istilah-istilah tersebut memiliki arti yang kurang lebih sama; mikrokernel merupakan terminologi modern.
| archive-date=2008-05-09
| archive-url=https://web.archive.org/web/20080509165551/http://l4ka.org/publications/2006/p95-heiser.pdf
| dead-url=yes
}}</ref>
namun implementasinya lebih bersifat minimalis, dan secara spesifik untuk mendukung pengimplementasian [[mesin virtual]]. Mikrokernel L4 sering juga disebut sebagai ''hypervisor'', yang mengindikasikan kemungkinan pengimplementasian sebuah mikrokernel sebagai ''hypervisor''. Istilah nanokernel dalam sejarahnya digunakan untuk membedakan mikrokernel saat ini dengan istilah mikrokernel sebelumnya yang menyediakan layanan sistem aktual, tetapi secara prinsip minimalitas menurut Jochen Liedtke dalam disain mikrokernel L4 menyebutkan bahwa istilah-istilah tersebut memiliki arti yang kurang lebih sama.


==Introduction==
== Pendahuluan ==
Pada mulanya, kernel sistem operasi umumnya berukuran kecil, penyebabnya adalah besarnya [[ingatan]] komputer yang terbatas. Dengan semakin berkembangnya kapabilitas komputer, jumlah perangkat yang harus dikendalikan oleh suatu kernel menjadi meningkat pula. Namun pada masa-masa awal sejarah sistem operasi [[UNIX|unix]], kernel pada umumnya berukuran kecil, meskipun kernel-kernel tersebut menyediakan [[device driver]] dan pengatur [[sistem berkas]]. Saat pengalamatan ruang meningkat dari 16 menjadi 32 bit, disain kernel diubahsuai menjadi tidak lagi bergantung pada arsitektur perangkat keras yang ada, dan ukuran kernel pun mulai tumbuh membesar.
Early operating system kernels were rather small, partly because computer memory was limited. As the capability of computers grew, the number of devices the kernel had to control also grew. Through the early history of [[Unix]], kernels were generally small, even though those kernels contained device drivers and file system managers. When address spaces increased from 16 to 32 bits, kernel design was no longer cramped by the hardware architecture, and kernels began to grow.


Berkeley [[UNIX]] ([[BSD]]) tercatat sebagai yang memulai era kernel berukuran besar. Sebagai tambahan dari pengoperasian sistem yang paling mendasar seperti [[CPU]], media penyimpanan, dan [[pencetak]], BSD mulai menambahkan [[sistem berkas]], sistem jaringan TCP/IP yang lengkap, dan sejumlah perangkat "virtual" yang mengizinkan program yang ada untuk bekerja secara tersembunyi pada jaringan. Pertumbuhan ini berlanjut selama beberapa dekade dan menyebabkan kernel yang ada saat ini terdiri hingga jutaan baris kode. Sebagai akibat dari pertumbuhan ini pun, kernel yang ada saat ini lebih rentan terhadap [[bug]] dan menjadi lebih sulit untuk dikelola.
Berkeley [[UNIX]] ([[BSD]]) began the era of big kernels. In addition to operating a basic system consisting of the CPU, disks and printers, BSD started adding additional [[file system]]s, a complete [[protocol stack|TCP/IP networking system]], and a number of "virtual" devices that allowed the existing programs to work invisibly over the network. This growth continued for several decades, resulting in kernels with millions of lines of [[source code]]. As a result of this growth, kernels were more prone to bugs and became increasingly difficult to maintain.


Mikrokernel dirancang untuk mengatasi permasalahan yang disebabkan karena pertumbuhan kernel yang membesar dan kesulitan mengelolanya. Secara teori, desain mikrokernel mengizinkan pengelolaan kode yang lebih mudah karena arsitekturnya yang mendistribusikan layanan pada area ruang pengguna. Pengimplementasian seperti ini berdampak positif pula pada peningkatan keamanan dan stabilitas sistem disebabkan karena menurunnya jumlah kode yang berjalan pada modus kernel. Sebagai contoh, jika layanan jaringan tidak bekerja karena serangan ''buffer overflow'', sistem lainnya masih dapat berfungsi secara normal.
The microkernel was designed to address the increasing growth of kernels and the difficulties that came with them. In theory, the microkernel design allows for easier management of code due to its division into [[user space]] services. This also allows for increased security and stability resulting from the reduced amount of code running in [[kernel mode]]. For example, if a networking service crashed due to [[buffer overflow]], only the networking service's memory would be corrupted, leaving the rest of the system still functional.


== Komunikasi antarproses ==
==Inter-process communication==
[[Interprocess Communication|Komunikasi antarproses]] (IPC) merupakan suatu mekanisme yang memungkinkan beberapa proses yang terpisah untuk saling berkomunikasi satu dengan lainnya, umumnya hal ini dilakukan dengan memanfaatkan mekanisme pengiriman pesan. Selain itu ingatan berbagi (''shared memory'') secara spesifik juga sering pula digunakan sebagai salah satu mekanisme komunikasi antarproses, tetapi demikian, umumnya makna IPC lebih mengarah pada komunikasi memanfaatkan mekanisme pengiriman pesan, dan lebih lanjut menjadi relevan terhadap mekanisme yang digunakan pada mikrokernel. IPC mengizinkan sistem operasi dibuat dari sejumlah program kecil yang disebut pelayan, yang digunakan oleh program lainnya dalam sistem, melalui IPC sebagai mediator. Hampir dari semua dukungan atas periferal perangkat keras ditangani melalui cara ini, dengan peladen atas device driver, protokol jaringan, sistem berkas, grafis, dan lain-lain.


IPC dapat pula berjalan secara sinkronis, dan asinkronis. Analogi IPC asinkronis pada komunikasi jaringan contohnya: pesan dikirim oleh program pengirim dan melanjutkan proses tanpa menunggu pesan baliknya. Program penerima menampung/mengecek keberadaan pesan yang harus diproses baik secara inisialisasi mandiri, atau diingatkan oleh suatu mekanisme notifikasi. IPC asinkronis mensyaratkan kernel mengelola penampung dan mengimplementasikan antrian atas pesan-pesan tersebut, dan berkompromi terhadap kemungkinan terjadinya ''buffer overflow''; Kernel juga harus melakukan duplikasi pesan (pengirim-ke-kernel dan kernel-ke-penerima). Sementara pada IPC sinkronis, pihak pertama (baik pengirim atau penerima) yang melakukan blokade hingga pihak yang dituju siap untuk melakukan proses IPC. Modus IPC sinkronis tidak membutuhkan pengelolaan penampung di sisi kernel, ataupun duplikasi pesan, tetapi komunikasi yang bersifat sinkronis seperti ini akan menyebabkan pemrograman menjadi lebih sulit. Kebanyakan programer lebih memilih menggunakan modus asinkronis untuk pengiriman dan modus sinkronis untuk penerimaan.
[[Inter-process communication]] (IPC) is any mechanism which allows separate processes to communicate with each other, usually by sending [[Message passing|messages]]. [[Shared memory]] is strictly speaking also an inter-process communication mechanism, but the acronym IPC usually only refers to message passing, and it is the latter that is particularly relevant to microkernels. IPC allows the operating system to be built from a number of small programs called servers, which are used by other programs on the system, invoked via IPC. Most or all support for peripheral hardware is handled in this fashion, with servers for device drivers, network protocol stacks, file systems, graphics, etc.


== Peladen ==
IPC can be synchronous or asynchronous. Asynchronous IPC is analogous to network communication: the sender dispatches a message and continues executing. The receiver checks (polls) for the availability of the message by attempting a receive, or is alerted to it via some notification mechanism. Asynchronous IPC requires that the kernel maintains buffers and queues for messages, and deals with buffer overflows; it also requires double copying of messages (sender to kernel and kernel to receiver). In synchronous IPC, the first party (sender or receiver) blocks until the other party is ready to perform the IPC. It does not require buffering or multiple copies, but the implicit rendezvous can make programming tricky. Most programmers prefer asynchronous send and synchronous receive.
Peladen mikrokernel pada dasarnya merupakan program [[daemon]] biasa seperti umumnya, dengan pengecualian kernel memberikan sejumlah kewenangan untuk berinteraksi dengan sebagian dari ingatan fisik yang biasanya dibatasi untuk program pada umumnya. Dengan cara demikian, hal ini memungkinkan para peladen, khususnya device driver, bisa berinteraksi secara langsung dengan perangkat keras.


Seperangkat peladen pada mikrokernel untuk kebutuhan umum melingkupi peladen [[sistem berkas]], peladen device driver, peladen jaringan, pelanden tampilan, dan peladen antar muka pengguna. Seperangkat peladen tersebut secara kasar adalah menyediakan sejumlah layanan yang sama yang diberikan pada kernel monolitik UNIX. Peladen yang dibutuhkan akan dijalankan pada saat sistem mulai berjalan dan secara aktif menyediakan layanan, seperti berkas, jaringan, dan akses terhadap perangkat, pada program-program aplikasi. Dengan sejumlah peladen yang berjalan pada lingkungan aplikasi pengguna seperti ini, pengembangan sebuah peladen sama seperti halnya halnya pengembangan aplikasi umum biasa.
First-generation microkernels typically supported synchronous as well as asynchronous IPC, and suffered from poor IPC performance. [[Jochen Liedtke]] identified design and implementation of the IPC mechanisms as the underlying reason for this poor performance. In his [[L4 microkernel family|L4 microkernel]] he pioneered techniques that lead to an [[order of magnitude|order-of-magnitude]] reduction of IPC costs.<ref name="Liedtke_93">{{cite conference
| first = Jochen
| last = Liedtke
| authorlink = Jochen Liedtke
| coauthors =
| title = Improving IPC by kernel design
| booktitle = 14th ACM Symposium on Operating System Principles
| pages = 175&ndash;88
| publisher =
| month = December
| year = 1993
| location = Asheville, NC, USA
| url = http://portal.acm.org/citation.cfm?id=168619.168633&coll=portal&dl=ACM&type=series&idx=168619&part=Proceedings&WantType=Proceedings&title=ACM%20Symposium%20on%20Operating%20Systems%20Principles&CFID=18793560&CFTOKEN=54028606
| accessdate =
| id =
}}</ref> These include an IPC system call that supports a send as well as a receive operation, making all IPC synchronous, and passing as much data as possible in registers. Furthermore, Liedtke introduced the concept of the ''direct process switch'', where during an IPC execution an (incomplete) [[context switch]] is performed from the sender directly to the receiver. If, as in L4, part or all of the message is passed in registers, this transfers the in-register part of the message without any copying at all. Furthermore, the overhead of invoking the scheduler is avoided; this is especially beneficial in the common case where IPC is used in an [[remote procedure call|RPC]]-type fashion by a client invoking a server. Another optimization, called ''lazy scheduling'', avoids traversing scheduling queues during IPC by leaving threads that block during IPC in the ready queue. Once the scheduler is invoked, it moves such threads to the appropriate waiting queue. As in many cases a thread gets unblocked before the next scheduler invocation, this approach saves significant work. Similar approaches have since been adopted by [[QNX]] and [[MINIX 3]].


== Device driver ==
In a client-server system, most communication is essentially synchronous, even if using asynchronous primitives, as the typical operation is a client invoking a server and then waiting for a reply. As it also lends itself to more efficient implementation, modern microkernels generally follow L4's lead and only provide a synchronous IPC primitive. Asynchronous IPC can be implemented on top by using helper threads. However, versions of L4 deployed in commercial products have found it necessary to add an asynchronous notification mechanism to better support asynchronous communication. This [[signal (computing)|signal]]-like mechanism does not carry data and therefore does not require buffering by the kernel.
[[Device driver]] secara frekuentif melakukan akses pengingat langsung ([[DMA]]), dengan demikian device driver bisa melakukan pennulisan dan relokasi atas ingatan fisik, termasuk pula struktur data kernel, oleh karena itu terhadap driver tersebut perlu diberikan kewenangan khusus (''trusted''). Kekeliruan konsepsi yang terjadi menganggap bahwa untuk device driver seperti itu haruslah merupakan bagian dari kernel. Padahal faktanya, driver tidak selalu menjadi bagian yang tidak terpisahkan dari kernel.


== Komponen-komponen mendasar dan minimalitas ==
As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to deadlocks. Furthermore, a client could easily mount a [[denial-of-service]] attack on a server by sending a request and never attempting to receive the reply. Therefore synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide [[timeout (telecommunication)|timeouts]] on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts, as does QNX).


Karena sebuah mikrokernal harus dapat meletakkan layanan-layanan sistem operasi pada level teratas, fungsionalitas yang harus dimiliki oleh mikrokernel setidaknya melingkupi:
==Servers==
Microkernel servers are essentially [[daemon (computer software)|daemon]] programs like any others, except that the kernel grants some of them privileges to interact with parts of physical memory that are otherwise off limits to most programs. This allows some servers, particularly device drivers, to interact directly with hardware.


* Mekanisme pengaturan pengalamatan ruang, — dibutuhkan untuk mengatur proteksi ingatan.
A basic set of servers for a general-purpose microkernel includes file system servers, device driver servers, networking servers, display servers, and user interface device servers. This set of servers (drawn from [[QNX]]) provides roughly the set of services offered by a monolithic UNIX kernel. The necessary servers are started at system startup and provide services, such as file, network, and device access, to ordinary application programs. With such servers running in the environment of a user application, server development is similar to ordinary application development, rather than the build-and-boot process needed for kernel development.
* Mekanisme eksekusi secara abstrak untuk mengatur alokasi [[CPU]] — biasanya adalah [[thread]] atau pengaktifan penjadual; dan
* [[Interprocess Communication|Komunikasi antarproses]] — dibutuhkan untuk menyediakan mekanisme pemanggilan peladen yang berjalan pada alamat ruang spesifik.


Hal terpenting yang harus dimiliki oleh sebuah mikrokernel adalah keberadaan mekanisme [[Interprocess Communication|Komunikasi antarproses]] yang handal, dan disain pengatur ingatan virtual yang memungkinkan manajemen ingatan dan melakukan pertukaran alamat (''swapping'') secara dengan aman. Selanjutnya, karena pada akhirnya semua layanan sistem operasi dipanggil oleh program yang berjalan pada modus user membuat tingkat efisiensi mekanisme komunikasi antar program yang terdapat pada sebuah mikrokernel menjadi sangat penting.
Additionally, many "crashes" can be corrected for by simply [[Crash-only software|stopping and restarting the server]]. However, part of the system state is lost with the failing server, hence this approach requires applications to cope with failure. A good example is a server responsible for [[Internet protocol suite|TCP/IP]] connections: If this server is restarted, applications will experience a "lost" connection, a normal occurrence in networked system. For other services, failure is less expected and may require changes to application code. For QNX, restart capability is offered as the QNX High Availability Toolkit.<ref>[http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf QNX High Availability Toolkit]</ref>


== Unjuk kerja ==
In order to make all servers restartable, some microkernels have concentrated on adding various [[database]]-like techniques like [[database transaction|transaction]]s, [[Replication (computer science)|replication]] and [[checkpointing]] in order to preserve essential state across single server restarts. An example is [[ChorusOS]], which was targeted at high-availability applications in the [[telecommunication]]s world. Chorus included features to allow any "properly written" server to be restarted at any time, with clients using those servers being paused while the server brought itself back into its original state.{{Fact|date=February 2007}} However, such kernel features are incompatible with the minimality principle, and are therefore not provided in modern microkernels, which instead rely on appropriate user-level protocols.
Pada sistem berbasis mikrokernel, permintaan atas suatu layanan melalaui IPC sebenarnya membutuhkan sumber daya yang lebih besar dibandingkan pada sistem dengan kernel berbasis monolitik yang hanya menggunakan pemanggilan tunggal secara internal sistem. Dengan demikian unjuk kerja sistem berbasis mikrokernel mungkin menimbulkan potensi masalah, sebagai contoh, unjuk kerja mikrokernel generasi pertama, Mach dan Chorus, menunjukkan hasil yang mengecewakan.<ref name="Chen_Bershad_93">{{cite conference

==Device drivers==

[[Device driver]]s frequently perform [[direct memory access]] (DMA), and therefore can write to arbitrary locations of physical memory, including over kernel data structures. Such drivers must therefore be trusted. It is a common misconception that this means that they must be part of the kernel. In fact, a driver is not inherently more or less trustworthy by being part of the kernel.

While running a device driver in user space does not necessarily reduce the damage a misbehaving driver can cause, in practice it is beneficial for system stability in the presence of buggy (rather than malicious) drivers: memory-access violations by the driver code itself (as opposed to the device) may still be caught by the memory-management hardware. Furthermore, many devices are not DMA-capable, their drivers can be made untrusted by running them in user space. Recently, an increasing number of computers feature [[IOMMU]]s, many of which can be used to restrict a device's access to physical memory.<ref name="Wong_07">{{cite journal|title = I/O, I/O, It's Off to Virtual Work We Go|url=http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=15350|author=Wong, William|journal=Electronic Design|date=April 27, 2007}}</ref> (IBM mainframes have had IO MMUs since the [[IBM System/360 Model 67]] and [[System/370]].) This also allows user-mode drivers to become untrusted.

User-mode drivers actually predate microkernels. The [[Michigan Terminal System]] (MTS), in 1967, supported user space drivers, the first operating system to be designed with that capability.<ref>{{cite journal|title=Organization and Features of the Michigan Terminal System|author=Alexander, M.T.|journal=AFIPS Conference Proceedings, 1972 Spring Joint Computer Conference|volume=40|year=1972|pages=589}}</ref>
Historically, drivers were less of a problem, as the number of devices was small and trusted anyway, so having them in the kernel simplified the design and avoided potential performance problems. This led to the traditional driver-in-the-kernel style of UNIX, Linux, and Windows.<ref name="Lions book">{{cite book|title=[[Lions' Commentary on UNIX 6th Edition, with Source Code]]|author=Lions, John|date=August 1, 1977|isbn=1573980137|publisher=Peer-To-Peer Communications}}</ref>
With the proliferation of various kinds of peripherals, the amount of driver code escalated and in modern operating systems dominates the kernel in terms of code size.

==Essential components & minimality==

As a microkernel must allow building arbitrary operating-system services on top, it must provide some core functionality. At the least this includes:
* some mechanisms for dealing with [[address space]]s — this is required for managing memory protection;
* some execution abstraction to manage CPU allocation — typically [[thread (computer science)|threads]] or [[scheduler activation]]s; and
* [[inter-process communication]] — required to invoke servers running in their own address spaces.
This minimal design was pioneered by [[Brinch Hansen]]'s [[RC 4000 Multiprogramming System|Nucleus]] and the hypervisor of IBM's [[VM (operating system)|VM]]. It has since been formalised in Liedtke's ''minimality principle'':
<blockquote>A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality.<ref name="Liedtke_95">{{cite conference | first=Jochen | last=Liedtke
| authorlink = Jochen Liedtke |title=On µ-Kernel Construction | booktitle = 15th ACM symposium on Operating Systems Principles | pages=237&ndash;250 | year=1995 | month=December | url=http://portal.acm.org/citation.cfm?id=224056.224075&coll=portal&dl=ACM&type=series&idx=224056&part=Proceedings&WantType=Proceedings&title=ACM%20Symposium%20on%20Operating%20Systems%20Principles&CFID=18793560&CFTOKEN=54028606
}}</ref></blockquote>
Everything else can be done in a user program, although device drivers implemented as user programs may require special privileges to access I/O hardware.

Related to the minimality principle, and equally important for microkernel design, is the [[separation of mechanism and policy]], it is what enables the construction of arbitrary systems on top of a minimal kernel. Any policy built into the kernel cannot be overwritten at user level and therefore limits the generality of the microkernel.<ref name="Liedtke_96">Previously cited</ref>
Policy implemented in user-level servers can be changed by replacing the servers (or letting the application choose between competing servers offering similar services).

For efficiency, most microkernels contain schedulers and manage timers, in violation of the minimality principle and the principle of policy-mechanism separation.

Start up ([[booting]]) of a microkernel-based system requires [[device drivers]], which are not part of the kernel. Typically this means that they are packaged with the kernel in the boot image, and the kernel supports a bootstrap protocol that defines how the drivers are located and started. Some microkernels simplify this by placing some key drivers inside the kernel (in violation of the minimality principle), [[LynxOS]] and the original [[Minix]] are examples. Some even include a [[file system]] in the kernel to simplify booting. On other cases microkernel-based system may boot via multiboot compatible boot loader, [[GNU GRUB]] for example, such systems usually loads statically linked servers to make an initial bootstrap or mount OS image to continue bootstrapping.

A key component of a microkernel is a good [[Inter-process communication|IPC]] system and virtual memory manager design that allows to implement page fault handling and swapping in user space servers side in a safe way. Since all services are performed by usermode programs, efficient means of communication between programs are essential, far more so than in monolithic kernels. The design of the IPC system makes or breaks a microkernel. To be effective, the IPC system must not only have low overhead, but also interact well with CPU scheduling.

==Performance==
Obtaining a service is inherently more expensive in a microkernel-based system than a monolithic system.<ref name="Liedtke_96">Previously cited</ref> In the monolithic system, the service is obtained by a single system call, which requires two ''mode switches'' (changes of the processor's [[privilege level]]). In the microkernel-based system, the service is obtained by sending an IPC message to a server, and obtaining the result in another IPC message from the server. This requires a [[context switch]] if the drivers are implemented as processes, or a function call if they are implemented as procedures. In addition, passing actual data to the server and back may incur extra copying overhead, while in a monolithic system the kernel can directly access the data in the client's buffers.

Performance is therefore a potential issue in microkernel systems. Indeed, the experience of first-generation microkernels such as [[Mach (kernel)|Mach]] and Chorus showed that systems based on them performed very poorly.<ref name="Chen_Bershad_93">{{cite conference
| first = Bradley
| first = Bradley
| last = Chen
| last = Chen
Baris 124: Baris 82:
| title = The Impact of Operating System Structure on Memory System Performance
| title = The Impact of Operating System Structure on Memory System Performance
| booktitle = 14th ACM Symposium on Operating System Principles
| booktitle = 14th ACM Symposium on Operating System Principles
| pages = 120&ndash;33
| pages = 120–33
| publisher =
| publisher =
| month = December
| month = December
Baris 131: Baris 89:
| accessdate =
| accessdate =
| id =
| id =
}}</ref> Namun, Jochen Liedtke menunjukkan bahwa masalah unjuk kerja Mach lebih terkait pada kesalahan disain dan implementasi. Melalui demonstrasi yang ditunjukkannya pada mikrokernel L4, ia berhasil menujukkan bahwa dengan menggunakan disain dan implementasi yang dirancang dengan baik serta konsisten dalam menerapkan prinsip-prinsip minimalitas, permasalahan yang terkait dengan IPC bisa diminimalisir.<ref name="Liedtke_ESHHIJ_97">{{cite conference
}}</ref>
However, [[Jochen Liedtke]] showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive [[cache]] footprint.<ref name="Liedtke_95">Previously cited</ref>
Liedtke demonstrated with his own [[L4 microkernel]] that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. L4's IPC performance is still unbeaten across a range of architectures.<ref name="Liedtke_ESHHIJ_97">{{cite conference
| first = Jochen
| first = Jochen
| last = Liedtke
| last = Liedtke
Baris 140: Baris 96:
| title = Achieved IPC performance (still the foundation for extensibility)
| title = Achieved IPC performance (still the foundation for extensibility)
| booktitle = 6th Workshop on Hot Topics in Operating Systems
| booktitle = 6th Workshop on Hot Topics in Operating Systems
| pages = 28&ndash;31
| pages = 28–31
| publisher = IEEE
| publisher = IEEE
| month = May | year = 1997
| month = May | year = 1997
Baris 148: Baris 104:
| id =
| id =
}}</ref><ref name="Gray_CCMH_05">{{cite conference
}}</ref><ref name="Gray_CCMH_05">{{cite conference
|first=Charles |last=Gray |coauthors=Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; [[Gernot Heiser|Heiser, Gernot]] |title=Itanium&mdash;a system implementor's tale |booktitle=USENIX Annual Technical Conference |pages=264&ndash;278 |date=April 2005|location=Annaheim, CA, USA |url=http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html
|first=Charles |last=Gray |coauthors=Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; [[Gernot Heiser|Heiser, Gernot]] |title=Itanium—a system implementor's tale |booktitle=USENIX Annual Technical Conference |pages=264–278 |date=April 2005|location=Annaheim, CA, USA |url=http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html
}}</ref><ref name="vanSchaik_Heiser_07">
}}</ref><ref name="vanSchaik_Heiser_07">{{cite conference
{{cite conference
| first = Carl
| first = Carl
| last = van Schaik
| last = van Schaik
Baris 156: Baris 111:
| title = High-performance microkernels and virtualisation on ARM and segmented architectures
| title = High-performance microkernels and virtualisation on ARM and segmented architectures
| booktitle = 1st International Workshop on Microkernels for Embedded Systems
| booktitle = 1st International Workshop on Microkernels for Embedded Systems
| pages = 11&ndash;21
| pages = 11–21
| publisher = NICTA
| publisher = NICTA
| date = January 2007
| date = January 2007
Baris 163: Baris 118:
| accessdate = 2007-04-01
| accessdate = 2007-04-01
| id =
| id =
| archive-date = 2007-04-26
}}</ref>
| archive-url = https://web.archive.org/web/20070426092901/http://ertos.nicta.com.au/publications
| dead-url = yes
}}</ref>


== Keamanan ==
While these results demonstrate that the poor performance of systems based on first-generation microkernels is not representative for second-generation kernels such as L4, this constitutes no proof that microkernel-based systems can be built with good performance. It has been shown that a monolithic Linux server ported to L4 exhibits only a few percent overhead over native Linux.<ref name="Hartig_97">{{cite journal | first = Hermann | last = Härtig |
Manfaat tingkat keamanan yang lebih baik atas pengimplementasian mikrokernel sering kali didiskusikan.<ref>[[Andrew S. Tanenbaum|Tanenbaum, Andrew S.]], [http://www.cs.vu.nl/~ast/reliable-os/ Tanenbaum-Torvalds debate, part II]</ref><ref>Tanenbaum, A., Herder, J. and Bos, H. (May 2006).</ref> Dalam konteks keamanan, prinsip minimalitas mikrokernel merupakan suatu konsekuensi manfaat langsung atas prinsip kewenangan minimal (''least privilege''), terkait dengan implementasi seluruh kode hanya membutuhkan kewenangan minimal yang dibutuhkan sebatas untuk menjalankan fungsionalitasnya. Sejauh kernel (kode yang berjalan dengan kewenangan penuh atas perangkat keras) senantiasa menjadi bagian dari basis komputasi tepercaya (''trusted computing base - TCB''), meminimalisirnya menjadi hal yang sewajarnya dalam disain keamanan terkendali.
coauthors=Hohmuth, Michael; [[Jochen Liedtke|Liedtke, Jochen]]; Schönberg, Sebastian|title=The performance of µ-kernel-based systems | journal = Proceedings of the sixteenth ACM symposium on Operating systems principles | year=1997 | month = October|id=ISBN 0-89791-916-5 | url = http://portal.acm.org/citation.cfm?id=266660&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 | pages=66&ndash;77|doi=10.1145/268998.266660 }}</ref>
However, such a single-server system exhibits few, if any, of the advantages microkernels are supposed to provide by structuring operating-system functionality into separate servers.

A number of commercial multi-server systems exist, in particular the [[Real-time operating system|real-time systems]] [[QNX]] and [[Integrity (operating system)| Integrity]]. No comprehensive comparison of performance relative to monolithic systems has been published for those multiserver systems. Furthermore, performance does not seem to be the overriding concern for those commercial systems, which instead emphasize simplicity for the sake of robustness. An attempt to build a high-performance multiserver operating system was the IBM Sawmill Linux project.<ref name="Gefflaut_JPLEUTDR_00">
{{ cite conference
| first = Alain
| last = Gefflaut
| coauthors = Jaeger, Trent; Park, Yoonho; [[Jochen Liedtke|Liedtke, Jochen]]; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; Reuther, Lars
| title = The Sawmill multiserver approach
| booktitle = 9th ACM SIGOPS European Worshop
| location = Kolding, Denmark
| pages = 109&ndash;114
| year = 2000
}}</ref>
However, this project was never completed.

It has been shown in the meantime that user-level device drivers can come close to the performance of in-kernel drivers even for such high-throughput, high-interrupt devices as Gigabit Ethernet.<ref name="Leslie_CFGGMPSEH_05">{{cite journal |last=Leslie |first=Ben |coauthors=Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; [[Gernot Heiser|Heiser, Gernot]] |year=2005 |month=September |title=User-level device drivers: achieved performance |journal=Journal of Computer Science and Technology |volume=5 |issue=20 |pages=654&ndash;664 |doi=10.1007/s11390-005-0654-4}}</ref> This seems to imply that high-performance multi-server systems are possible.

==Security==
The security benefits of microkernels have been frequently discussed.<ref>[[Andrew S. Tanenbaum|Tanenbaum, Andrew S.]], [http://www.cs.vu.nl/~ast/reliable-os/ Tanenbaum-Torvalds debate, part II]</ref><ref>Tanenbaum, A., Herder, J. and Bos, H. (May 2006). </ref> In the context of security the minimality principle of microkernels is a direct consequence of the principle of [[least privilege]], according to which all code should have only the privileges needed to provide required functionality. Minimality requires that a system's [[trusted computing base]] (TCB) should be kept minimal. As the kernel (the code that executes in the privileged mode of the hardware) is always part of the TCB, minimizing it is natural in a security-driven design.

Consequently, microkernel designs have been used for systems designed for high-security applications, including [[KeyKOS]], [[Extremely Reliable Operating System|EROS]] and military systems. In fact [[common criteria]] (CC) at the highest assurance level (EAL7) has an explicit requirement that the target of evaluation be “simple”, an acknowledgment of the practical impossibility of establishing true trustworthiness for a complex system.

Recent work on microkernels is focusing on formal specifications of the kernel API, and formal proofs of security properties of the API. The first example of this is a mathematical proof of the confinement mechanisms in EROS, based on a simplified model of the EROS API.<ref>{{cite conference
| first = Jonathan S.
| last = Shapiro
| authorlink = Jonathan Shapiro
| coauthors = Weber, Samuel
| title = Verifying the EROS Confinement Mechanism
| booktitle = IEEE Conference on Security and Privacy
| pages =
| publisher =
| date =
| location =
| url = http://www.eros-os.org/papers/oakland2000.ps
| doi =
| id =
| accessdate = }}</ref> More recently, a comprehensive set of machine-checked proofs has been performed of the properties of the protection model of the seL4 version of L4.<ref>{{Citation
| first = Dhammika
| last = Elkaduwe
| author-link =
| first2 = Gerwin
| last2 = Klein
| first3 = Kevin
| last3 = Elphinstone
| author2-link =
| editor-last =
| editor-first =
| editor2-last =
| editor2-first =
| contribution =
| contribution-url =
| title =Verified Protection Model of the seL4 Microkernel
| year = 2007
| pages =
| place =
| publisher = submitted for publication
| url = http://ertos.org/publications/papers/Elkaduwe_GE_07.abstract
| doi =
| id = }}</ref>

Some projects go even further, aiming at complete formal verification, i.e. a mathematical proof that the kernel's implementation is consistent with its specification, which then provides a guarantee that the properties proved about the API actually hold for the real kernel. This degree of assurance goes beyond even CC EAL7. Such proofs are being attempted for [[Coyotos]] and [http://ertos.org/research/l4.verified seL4].


== Nanokernel ==
== Nanokernel ==
In [[computer science]], the term '''nanokernel''' or '''picokernel''' historically referred to:
Dalam ilmu komputer, istilah '''nanokernel''' atau '''picokernel''' lebih mengarah pada:
# A kernel where the total amount of kernel code, i.e. code executing in the privileged mode of the hardware, is very small. The term '''picokernel''' was sometimes used to further emphasize small size. The term '''nanokernel''' was coined by [[Jonathan S. Shapiro]] in the paper [http://citeseer.ist.psu.edu/135535.html ''The KeyKOS NanoKernel Architecture'']. It was a sardonic response to Mach, which claimed to be a microkernel while being monolithic, essentially unstructured, and slower than the systems it sought to replace. Subsequent reuse of and response to the term, including the picokernel coinage, suggest that the point was largely missed. Both '''nanokernel''' and '''picokernel''' have subsequently come to have the same meaning expressed by the term [[microkernel]].
# Sebuah kernel dengan total jumlah kode, yang berjalan dalam modus kewenangan penuh atas perangkat keras, sangat kecil. Istilah '''picokernel''' kadang-kadang digunakan untuk lebih menekankan pada kecilnya ukuran. Sementara istilah '''nanokernel''' pertama kali dikemukakan oleh Jonathan S. Shapiro dalam makalah [http://citeseer.ist.psu.edu/135535.html ''The KeyKOS NanoKernel Architecture''] yang merupakan respon tajam atas mikrokernel Mach, yang mengklaim mikrokernal meski kode yang ada bersifat monolitik, tidak terstruktur, dan lebih lamban dari sistem yang ada sebelumnya.
# Sebuah virtualisasi lapisan yang terdapat pada sistem operasi; lebih tepatnya mengacu pada sebuah hypervisor
# A virtualization layer underneath an operating system; this is more correctly referred to as a [[hypervisor]].
# Sebuah abstraksi lapisan perangkat keras yang bekerja pada bagian tingkat-terbawah dari kernel.
# A [[hardware abstraction layer]] that forms the lowest-level part of a kernel, sometimes used to provide [[Real-time computing|real-time]] functionality to normal OS's, like [[Adeos]].

There is also at least one case where the term nanokernel is used to refer not to a small kernel, but one that supports a nanosecond clock resolution. [http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf]

==See also==
*[[Kernel (computer science)]]
**[[Exokernel]], a research kernel architecture with a more minimalist approach to kernel technology.
**[[Hybrid kernel]]
**[[Monolithic kernel]]
**[[Loadable kernel module]]
*[[Trusted computing base]]


== References ==
== Referensi ==
{{Reflist}}
{{Reflist}}


== Bacaan lanjutan ==
==Further reading==
*[http://citeseer.csail.mit.edu/cs?q=microkernel scientific articles about microkernels] (on [[CiteSeer]]), including:
* {{en}} [http://citeseer.csail.mit.edu/cs?q=microkernel scientific articles about microkernels]{{Pranala mati|date=Februari 2021 |bot=InternetArchiveBot |fix-attempted=yes }}, termasuk:
** {{cite journal | author= Dan Hildebrand|title=An Architectural Overview of QNX|journal=Proceedings of the Workshop on Micro-kernels and Other Kernel Architectures | year=1992 |id=ISBN 1-880446-42-1 | pages=113–126 }} - the basic QNX reference.
** {{en}} {{cite journal | author= Dan Hildebrand|title=An Architectural Overview of QNX|journal=Proceedings of the Workshop on Micro-kernels and Other Kernel Architectures | year=1992 |id=ISBN 1-880446-42-1 | pages=113–126 }} - the basic QNX reference.
** {{cite journal | title=Can We Make Operating Systems Reliable and Secure? | author=Tanenbaum, A., Herder, J. and Bos, H.| journal = Computer| month = May | year = 2006 | url = http://www.computer.org/portal/site/computer/menuitem.eb7d70008ce52e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl |pages = 44–51}} -the basic reliable reference.
** {{en}} {{cite journal | title = Can We Make Operating Systems Reliable and Secure? | author = Tanenbaum, A., Herder, J. and Bos, H. | journal = Computer | month = May | year = 2006 | url = http://www.computer.org/portal/site/computer/menuitem.eb7d70008ce52e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl | pages = 44–51 | access-date = 2021-02-28 | archive-date = 2017-06-21 | archive-url = https://web.archive.org/web/20170621194406/https://www.computer.org/portal/site/computer/menuitem.eb7d70008ce52e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1&path=computer%2Fhomepage%2F0506&file=cover1.xml&xsl=article.xsl | dead-url = yes }} -the basic reliable reference.
** {{cite journal |title=Microkernel Operating System Architecture and Mach | author=Black, D.L., Golub, D.B., Julin, D.P., Rashid, R.F., Draves, R.P., Dean, R.W., Forin, A., Barrera, J., Tokuda, H., Malan, G., and Bohman, D. |journal=J. Of Information Processing|volume=14(4) | month=March | year=1992 }} - the basic Mach reference.
** {{en}} {{cite journal |title=Microkernel Operating System Architecture and Mach | author=Black, D.L., Golub, D.B., Julin, D.P., Rashid, R.F., Draves, R.P., Dean, R.W., Forin, A., Barrera, J., Tokuda, H., Malan, G., and Bohman, D. |journal=J. Of Information Processing|volume=14(4) | month=March | year=1992 }} - the basic Mach reference.
*[http://c2.com/cgi/wiki?MicroKernel MicroKernel page] from the [[Portland Pattern Repository]]
* {{en}} [http://c2.com/cgi/wiki?MicroKernel MicroKernel page] from the Portland Pattern Repository
* The [[Tanenbaum-Torvalds debate]]
* {{en}} [http://www.oreilly.com/catalog/opensources/book/appa.html The Tanenbaum-Torvalds Debate, 1992.01.29]
* {{en}} Tanenbaum, A. S. "[http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl& Can We Make Operating Systems Reliable and Secure?] {{Webarchive|url=https://web.archive.org/web/20180618202352/https://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer%2Fhomepage%2F0506&file=cover1.xml&xsl=article.xsl& |date=2018-06-18 }}".
**[http://www.oreilly.com/catalog/opensources/book/appa.html The Tanenbaum-Torvalds Debate, 1992.01.29]
* {{en}} Torvalds, L. [http://www.realworldtech.com/forums/index.cfm?action=detail&id=66630&threadid=66595&roomid=11 Linus Torvalds about the microkernels again, 2006.05.09]
** Tanenbaum, A. S. "[http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl& Can We Make Operating Systems Reliable and Secure?]".
* {{en}} Shapiro, J. "[http://www.coyotos.org/docs/misc/linus-rebuttal.html Debunking Linus's Latest] {{Webarchive|url=https://web.archive.org/web/20160922022726/http://www.coyotos.org/docs/misc/linus-rebuttal.html |date=2016-09-22 }}".
** Torvalds, L. [http://www.realworldtech.com/forums/index.cfm?action=detail&id=66630&threadid=66595&roomid=11 Linus Torvalds about the microkernels again, 2006.05.09]
** Shapiro, J. "[http://www.coyotos.org/docs/misc/linus-rebuttal.html Debunking Linus's Latest]".
* {{en}} Tanenbaum, A. S. "[http://www.cs.vu.nl/~ast/reliable-os/ Tanenbaum-Torvalds Debate: Part II]".
** Tanenbaum, A. S. "[http://www.cs.vu.nl/~ast/reliable-os/ Tanenbaum-Torvalds Debate: Part II]".


{{computer-stub}}
{{Sistem operasi}}


[[Kategori:Teknologi sistem operasi]]
[[Category:Operating system technology]]
[[Category:Microkernels]]


[[fi:Käyttöjärjestelmän ydin#Mikroydin]]
[[ca:Microkernel]]
[[cs:Mikrojádro]]
[[de:Mikrokernel]]
[[es:Micronúcleo]]
[[fr:Noyau de système d'exploitation#Systèmes à micro-noyaux]]
[[fr:Noyau de système d'exploitation#Systèmes à micro-noyaux]]
[[it:Kernel#Microkernel]]
[[hu:Mikrokernel]]
[[nl:Microkernel]]
[[ja:マイクロカーネル]]
[[no:Mikrokjerne]]
[[pl:Mikrojądro]]
[[pt:Micro-kernel]]
[[ru:Микроядро]]
[[sk:Mikrokernel]]
[[sv:Mikrokärna]]
[[uk:Мікроядро]]

Revisi terkini sejak 15 Oktober 2022 05.12

Stuktur sistem operasi berbasis mikrokernel monolitik

Dalam pengetahuan Ilmu Komputer, mikrokernel merupakan seperangkat perangkat lunak dalam jumlah minimum yang meyediakan beragam mekanisme dasar yang dibutuhkan untuk bekerja sebagai sebuah sistem operasi, seperti halnya manajemen pengalamatan ruang tingkat rendah, manajemen thread, dan komunikasi antar proses. Dalam implementasinya mikrokernel merupakan satu-satunya perangkat lunak yang berjalan dengan tingkat kewenangan tertinggi (umumnya disebut sebagai modus supervisor atau modus kernel) dari serangkaian level kewenangan yang tersedia pada perangkat kerasnya. Layanan yang disediakan oleh sebuah sistem operasi beberapa diantaranya adalah device driver, protokol jaringan, sistem berkas, dan kode antarmuka pengguna yang berada dalam ruang pengguna.

Mikrokernel sangat erat terkait dengan exokernel[1] , serta memiliki banyak kesamaan dengan hypervisor.[2] namun implementasinya lebih bersifat minimalis, dan secara spesifik untuk mendukung pengimplementasian mesin virtual. Mikrokernel L4 sering juga disebut sebagai hypervisor, yang mengindikasikan kemungkinan pengimplementasian sebuah mikrokernel sebagai hypervisor. Istilah nanokernel dalam sejarahnya digunakan untuk membedakan mikrokernel saat ini dengan istilah mikrokernel sebelumnya yang menyediakan layanan sistem aktual, tetapi secara prinsip minimalitas menurut Jochen Liedtke dalam disain mikrokernel L4 menyebutkan bahwa istilah-istilah tersebut memiliki arti yang kurang lebih sama.

Pendahuluan

[sunting | sunting sumber]

Pada mulanya, kernel sistem operasi umumnya berukuran kecil, penyebabnya adalah besarnya ingatan komputer yang terbatas. Dengan semakin berkembangnya kapabilitas komputer, jumlah perangkat yang harus dikendalikan oleh suatu kernel menjadi meningkat pula. Namun pada masa-masa awal sejarah sistem operasi unix, kernel pada umumnya berukuran kecil, meskipun kernel-kernel tersebut menyediakan device driver dan pengatur sistem berkas. Saat pengalamatan ruang meningkat dari 16 menjadi 32 bit, disain kernel diubahsuai menjadi tidak lagi bergantung pada arsitektur perangkat keras yang ada, dan ukuran kernel pun mulai tumbuh membesar.

Berkeley UNIX (BSD) tercatat sebagai yang memulai era kernel berukuran besar. Sebagai tambahan dari pengoperasian sistem yang paling mendasar seperti CPU, media penyimpanan, dan pencetak, BSD mulai menambahkan sistem berkas, sistem jaringan TCP/IP yang lengkap, dan sejumlah perangkat "virtual" yang mengizinkan program yang ada untuk bekerja secara tersembunyi pada jaringan. Pertumbuhan ini berlanjut selama beberapa dekade dan menyebabkan kernel yang ada saat ini terdiri hingga jutaan baris kode. Sebagai akibat dari pertumbuhan ini pun, kernel yang ada saat ini lebih rentan terhadap bug dan menjadi lebih sulit untuk dikelola.

Mikrokernel dirancang untuk mengatasi permasalahan yang disebabkan karena pertumbuhan kernel yang membesar dan kesulitan mengelolanya. Secara teori, desain mikrokernel mengizinkan pengelolaan kode yang lebih mudah karena arsitekturnya yang mendistribusikan layanan pada area ruang pengguna. Pengimplementasian seperti ini berdampak positif pula pada peningkatan keamanan dan stabilitas sistem disebabkan karena menurunnya jumlah kode yang berjalan pada modus kernel. Sebagai contoh, jika layanan jaringan tidak bekerja karena serangan buffer overflow, sistem lainnya masih dapat berfungsi secara normal.

Komunikasi antarproses

[sunting | sunting sumber]

Komunikasi antarproses (IPC) merupakan suatu mekanisme yang memungkinkan beberapa proses yang terpisah untuk saling berkomunikasi satu dengan lainnya, umumnya hal ini dilakukan dengan memanfaatkan mekanisme pengiriman pesan. Selain itu ingatan berbagi (shared memory) secara spesifik juga sering pula digunakan sebagai salah satu mekanisme komunikasi antarproses, tetapi demikian, umumnya makna IPC lebih mengarah pada komunikasi memanfaatkan mekanisme pengiriman pesan, dan lebih lanjut menjadi relevan terhadap mekanisme yang digunakan pada mikrokernel. IPC mengizinkan sistem operasi dibuat dari sejumlah program kecil yang disebut pelayan, yang digunakan oleh program lainnya dalam sistem, melalui IPC sebagai mediator. Hampir dari semua dukungan atas periferal perangkat keras ditangani melalui cara ini, dengan peladen atas device driver, protokol jaringan, sistem berkas, grafis, dan lain-lain.

IPC dapat pula berjalan secara sinkronis, dan asinkronis. Analogi IPC asinkronis pada komunikasi jaringan contohnya: pesan dikirim oleh program pengirim dan melanjutkan proses tanpa menunggu pesan baliknya. Program penerima menampung/mengecek keberadaan pesan yang harus diproses baik secara inisialisasi mandiri, atau diingatkan oleh suatu mekanisme notifikasi. IPC asinkronis mensyaratkan kernel mengelola penampung dan mengimplementasikan antrian atas pesan-pesan tersebut, dan berkompromi terhadap kemungkinan terjadinya buffer overflow; Kernel juga harus melakukan duplikasi pesan (pengirim-ke-kernel dan kernel-ke-penerima). Sementara pada IPC sinkronis, pihak pertama (baik pengirim atau penerima) yang melakukan blokade hingga pihak yang dituju siap untuk melakukan proses IPC. Modus IPC sinkronis tidak membutuhkan pengelolaan penampung di sisi kernel, ataupun duplikasi pesan, tetapi komunikasi yang bersifat sinkronis seperti ini akan menyebabkan pemrograman menjadi lebih sulit. Kebanyakan programer lebih memilih menggunakan modus asinkronis untuk pengiriman dan modus sinkronis untuk penerimaan.

Peladen

[sunting | sunting sumber]

Peladen mikrokernel pada dasarnya merupakan program daemon biasa seperti umumnya, dengan pengecualian kernel memberikan sejumlah kewenangan untuk berinteraksi dengan sebagian dari ingatan fisik yang biasanya dibatasi untuk program pada umumnya. Dengan cara demikian, hal ini memungkinkan para peladen, khususnya device driver, bisa berinteraksi secara langsung dengan perangkat keras.

Seperangkat peladen pada mikrokernel untuk kebutuhan umum melingkupi peladen sistem berkas, peladen device driver, peladen jaringan, pelanden tampilan, dan peladen antar muka pengguna. Seperangkat peladen tersebut secara kasar adalah menyediakan sejumlah layanan yang sama yang diberikan pada kernel monolitik UNIX. Peladen yang dibutuhkan akan dijalankan pada saat sistem mulai berjalan dan secara aktif menyediakan layanan, seperti berkas, jaringan, dan akses terhadap perangkat, pada program-program aplikasi. Dengan sejumlah peladen yang berjalan pada lingkungan aplikasi pengguna seperti ini, pengembangan sebuah peladen sama seperti halnya halnya pengembangan aplikasi umum biasa.

Device driver

[sunting | sunting sumber]

Device driver secara frekuentif melakukan akses pengingat langsung (DMA), dengan demikian device driver bisa melakukan pennulisan dan relokasi atas ingatan fisik, termasuk pula struktur data kernel, oleh karena itu terhadap driver tersebut perlu diberikan kewenangan khusus (trusted). Kekeliruan konsepsi yang terjadi menganggap bahwa untuk device driver seperti itu haruslah merupakan bagian dari kernel. Padahal faktanya, driver tidak selalu menjadi bagian yang tidak terpisahkan dari kernel.

Komponen-komponen mendasar dan minimalitas

[sunting | sunting sumber]

Karena sebuah mikrokernal harus dapat meletakkan layanan-layanan sistem operasi pada level teratas, fungsionalitas yang harus dimiliki oleh mikrokernel setidaknya melingkupi:

  • Mekanisme pengaturan pengalamatan ruang, — dibutuhkan untuk mengatur proteksi ingatan.
  • Mekanisme eksekusi secara abstrak untuk mengatur alokasi CPU — biasanya adalah thread atau pengaktifan penjadual; dan
  • Komunikasi antarproses — dibutuhkan untuk menyediakan mekanisme pemanggilan peladen yang berjalan pada alamat ruang spesifik.

Hal terpenting yang harus dimiliki oleh sebuah mikrokernel adalah keberadaan mekanisme Komunikasi antarproses yang handal, dan disain pengatur ingatan virtual yang memungkinkan manajemen ingatan dan melakukan pertukaran alamat (swapping) secara dengan aman. Selanjutnya, karena pada akhirnya semua layanan sistem operasi dipanggil oleh program yang berjalan pada modus user membuat tingkat efisiensi mekanisme komunikasi antar program yang terdapat pada sebuah mikrokernel menjadi sangat penting.

Unjuk kerja

[sunting | sunting sumber]

Pada sistem berbasis mikrokernel, permintaan atas suatu layanan melalaui IPC sebenarnya membutuhkan sumber daya yang lebih besar dibandingkan pada sistem dengan kernel berbasis monolitik yang hanya menggunakan pemanggilan tunggal secara internal sistem. Dengan demikian unjuk kerja sistem berbasis mikrokernel mungkin menimbulkan potensi masalah, sebagai contoh, unjuk kerja mikrokernel generasi pertama, Mach dan Chorus, menunjukkan hasil yang mengecewakan.[3] Namun, Jochen Liedtke menunjukkan bahwa masalah unjuk kerja Mach lebih terkait pada kesalahan disain dan implementasi. Melalui demonstrasi yang ditunjukkannya pada mikrokernel L4, ia berhasil menujukkan bahwa dengan menggunakan disain dan implementasi yang dirancang dengan baik serta konsisten dalam menerapkan prinsip-prinsip minimalitas, permasalahan yang terkait dengan IPC bisa diminimalisir.[4][5][6]

Keamanan

[sunting | sunting sumber]

Manfaat tingkat keamanan yang lebih baik atas pengimplementasian mikrokernel sering kali didiskusikan.[7][8] Dalam konteks keamanan, prinsip minimalitas mikrokernel merupakan suatu konsekuensi manfaat langsung atas prinsip kewenangan minimal (least privilege), terkait dengan implementasi seluruh kode hanya membutuhkan kewenangan minimal yang dibutuhkan sebatas untuk menjalankan fungsionalitasnya. Sejauh kernel (kode yang berjalan dengan kewenangan penuh atas perangkat keras) senantiasa menjadi bagian dari basis komputasi tepercaya (trusted computing base - TCB), meminimalisirnya menjadi hal yang sewajarnya dalam disain keamanan terkendali.

Nanokernel

[sunting | sunting sumber]

Dalam ilmu komputer, istilah nanokernel atau picokernel lebih mengarah pada:

  1. Sebuah kernel dengan total jumlah kode, yang berjalan dalam modus kewenangan penuh atas perangkat keras, sangat kecil. Istilah picokernel kadang-kadang digunakan untuk lebih menekankan pada kecilnya ukuran. Sementara istilah nanokernel pertama kali dikemukakan oleh Jonathan S. Shapiro dalam makalah The KeyKOS NanoKernel Architecture yang merupakan respon tajam atas mikrokernel Mach, yang mengklaim mikrokernal meski kode yang ada bersifat monolitik, tidak terstruktur, dan lebih lamban dari sistem yang ada sebelumnya.
  2. Sebuah virtualisasi lapisan yang terdapat pada sistem operasi; lebih tepatnya mengacu pada sebuah hypervisor
  3. Sebuah abstraksi lapisan perangkat keras yang bekerja pada bagian tingkat-terbawah dari kernel.

Referensi

[sunting | sunting sumber]
  1. ^ Liedtke, Jochen (1996). "Towards Real Microkernels". Communications of the ACM. 39 (9): 70–77. 
  2. ^ Heiser, Gernot; Uhlig, Volkmar and LeVasseur, Joshua (2006). "Are Virtual-Machine Monitors Microkernels Done Right?" (PDF). ACM SIGOPS Operating Systems Review. ACM. 40 (1): 95–99. doi:10.1145/1113361.1113363. Diarsipkan dari versi asli (PDF) tanggal 2008-05-09. Diakses tanggal 2009-03-23. 
  3. ^ Chen, Bradley (1993). "The Impact of Operating System Structure on Memory System Performance". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. hlm. 120–33. 
  4. ^ Liedtke, Jochen (1997). "Achieved IPC performance (still the foundation for extensibility)". 6th Workshop on Hot Topics in Operating Systems. Cape Cod, MA, USA: IEEE. hlm. 28–31. 
  5. ^ Gray, Charles (April 2005). "Itanium—a system implementor's tale". USENIX Annual Technical Conference. Annaheim, CA, USA. hlm. 264–278. 
  6. ^ van Schaik, Carl (January 2007). "High-performance microkernels and virtualisation on ARM and segmented architectures". 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. hlm. 11–21. Diarsipkan dari versi asli tanggal 2007-04-26. Diakses tanggal 2007-04-01. 
  7. ^ Tanenbaum, Andrew S., Tanenbaum-Torvalds debate, part II
  8. ^ Tanenbaum, A., Herder, J. and Bos, H. (May 2006).

Bacaan lanjutan

[sunting | sunting sumber]
Diperoleh dari "https://wiki-indonesia.club/w/index.php?title=Mikrokernel&oldid=21797057"