download dengan klik link ini - Komputasi

Pengantar Sistem 

Operasi: Sebuah 

Pendekatan Praktis 

Dengan Menggunakan 

Proyek OpenSolaris 

Buku Pedoman Siswa 

Qui ckTi m e and a 

de com p re ssor 

are needed to see thi s pi cture. 

SunMicrosystems,Inc. 

4150NetworkCircle SantaClara,CA95054 

USA

Copyright 2007 SunMicrosystems, Inc. 4150Network Circle, Santa Clara, 

CA 95054 U.S.A. All rights reserved. 

SunMicrosystems, Inc. has intellectual property rights relating to 

technology embodied in the product that is described in this document. 

In particular, and without limitation, these intellectual property 

rights may include one or more U.S. patents or pending patent 

applications in the U.S. and in other countries. 

U.S. Government Rights – Commercial software. Government users are 

subject to the SunMicrosystems, Inc. standard license agreement and 

applicable provisions of the FAR and its supplements. 

This distribution may include materials developed by third parties. 

Parts of the product may be derived from Berkeley BSD systems, licensed 

from the University of California. UNIX is a registered trademark in 

the U.S. and other countries, exclusively licensed through X/Open 

Company, Ltd. 

Sun, SunMicrosystems, the Sun logo, the Solaris logo, the Java Coffee 

Cup logo, docs.sun.com, Java, and Solaris are trademarks or registered 

trademarks of SunMicrosystems, Inc. in the U.S. and other countries. 

All SPARC trademarks are used under license and are trademarks or 

registered trademarks of SPARC International, Inc. in the U.S. and 

other countries. Products bearing SPARC trademarks are based upon an 

architecture developed by Sun Microsystems, Inc. 

TheOPEN LOOK and SunTM Graphical User Interface was developed by 

SunMicrosystems, Inc. for its users and licensees. Sun acknowledges the 

pioneering efforts of Xerox in researching and developing the concept 

of visual or graphical user interfaces for the computer industry. Sun 

holds a non-exclusive license from Xerox to the Xerox Graphical User 

Interface, which license also covers Sun's licensees who implementOPEN 

LOOK GUIs and otherwise comply with Sun's written license agreements. 

Products covered by and information contained in this publication are 

controlled by U.S. Export Control laws and may be subject to the export 

or import laws in other countries.Nuclear, missile, chemical or 

biological weapons or nuclear maritime end uses or end users, whether 

direct or indirect, are strictly prohibited. Export or reexport to 

countries subject to U.S. embargo or to entities identified on U.S. 

export exclusion lists, including, but not limited to, the denied 

persons and specially designated nationals lists is strictly prohibited. 

DOCUMENTATIONIS PROVIDED “AS IS” AND ALL EXPRESSOR IMPLIED CONDITIONS, 

REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTYOF 

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSEORNON-INFRINGEMENT, 

ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCHDISCLAIMERS ARE HELD TO 

BE LEGALLY INVALID. 

Copyright 2007 SunMicrosystems, Inc. 4150Network Circle, Santa Clara, 

CA 95054 U.S.A. Tous droits réservés. SunMicrosystems, Inc. détient les 

droits de propriété intellectuelle relatifs à la technologie incorporée 

dans le produit qui est décrit dans ce document. En particulier, et ce 

sans limitation, ces droits de propriété intellectuelle peuvent inclure 

Pengantar Sistem Operasi: Sebuah Pendekatan Praktis 

dengan Menggunakan Proyek OpenSolaris – Agustus 2007 

i

un ou plusieurs brevets américains ou des applications de brevet en 

attente aux Etats-Unis et dans d'autres pays. 

Cette distribution peut comprendre des composants développés par des 

tierces personnes. 

Certaines composants de ce produit peuvent être dérivées du logiciel 

Berkeley BSD, licenciés par l'Université de Californie. UNIX est une 

marque déposée aux Etats-Unis et dans d'autres pays; elle est licenciée 

exclusivement par X/Open Company, Ltd. 

Sun, SunMicrosystems, le logo Sun, le logo Solaris, le logo Java Coffee 

Cup, docs.sun.com, Java et Solaris sont des marques de fabrique ou des 

marques déposées de SunMicrosystems, Inc. aux Etats-Unis et dans 

d'autres pays. Toutes les marques SPARC sont utilisées sous licence et 

sont des marques de fabrique ou des marques déposées de SPARC 

International, Inc. aux Etats-Unis et dans d'autres pays. Les produits 

portant les marques SPARC sont basés sur une architecture développée 

par SunMicrosystems, Inc. 

L'interface d'utilisation graphiqueOPEN LOOK et Sun a été développée 

par SunMicrosystems, Inc. pour ses utilisateurs et licenciés. Sun 

reconnaît les efforts de pionniers de Xerox pour la recherche et le 

développement du concept des interfaces d'utilisation visuelle ou 

graphique pour l'industrie de l'informatique. Sun détient une licence 

non exclusive de Xerox sur l'interface d'utilisation graphique Xerox, 

cette licence couvrant également les licenciés de Sun qui mettent en 

place l'interface d'utilisation graphiqueOPEN LOOK et qui, en outre, se 

conforment aux licences écrites de Sun. 

Les produits qui font l'objet de cette publication et les informations 

qu'il contient sont régis par la legislation américaine en matière de 

contrôle des exportations et peuvent être soumis au droit d'autres pays 

dans le domaine des exportations et importations. Les utilisations 

finales, ou utilisateurs finaux, pour des armes nucléaires, des 

missiles, des armes chimiques ou biologiques ou pour le nucléaire 

maritime, directement ou indirectement, sont strictement interdites. 

Les exportations ou réexportations vers des pays sous embargo des 

Etats-Unis, ou vers des entités figurant sur les listes d'exclusion 

d'exportation américaines, y compris, mais de manière non exclusive, la 

liste de personnes qui font objet d'un ordre de ne pas participer, 

d'une façon directe ou indirecte, aux exportations des produits ou des 

services qui sont régis par la legislation américaine en matière de 

contrôle des exportations et la liste de ressortissants spécifiquement 

designés, sont rigoureusement interdites. 

LADOCUMENTATIONEST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CONDITIONS, 

DECLARATIONS ET GARANTIES EXPRESSESOUTACITES SONT FORMELLEMENT 

EXCLUES,DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y 

COMPRISNOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A 

LAQUALITEMARCHANDE, A L'APTITUDE A UNE UTILISATIONPARTICULIEREOUA 

L'ABSENCEDE CONTREFACON. 



ii



iii

Daftar Isi 

Daftar Isi .....................................iii 

Apa itu Proyek OpenSolaris? ......................1 

Portal Regional..................................3 

Situs-Situs OpenSolaris..........................4 

Diskusi........................................5 

Komunitas......................................6 

Proyek.........................................8 

Repositori Kode Pemograman.....................9 

OpenGrok......................................10 

Advokasi OpenSolaris.............................11 

Mengapa Menggunakan OpenSolaris?................12 

Harga.........................................13 

Fitur-fitur Inti Yang Inovatif................14 

Kompatibilitas Balik..........................15 

Netralitas Platform Perangkat Keras...........16 

Piranti Pengembangan..........................17 

Pernyatan Tanda Terima Kasih....................19 

Mempersiapkan Lingkungan Kerja OpenSolaris......20 

Konfigurasi Perangkat Keras dan Perangkat Lunak.22 

Jaringan........................................26 

Daemon Auto-Configuration Jaringan..............27 

Tinjauan Umum Zona..............................28 

Administrasi Zona...............................29 

Memulai Administrasi Zona.....................31 

Virtualisasi Server Web dengan Zona.............35 

Pembuatan Zona Non-Global.....................36 

Pembuatan Pool Penyimpan Data dan Sistem File ZFS 

................................................41 

Membuat Pool Penyimpan Data ZFS Ter-mirror......42 



iii

Membuat Sistem File ZFS Sebagai Direktori Kerja 

Pengguna........................................44 

Membuat Konfigurasi RAID-Z .....................48 

Konsolidasi Area Pengguna........................50 

Konsolisidasi Area Pengguna dan Deskripsinya....51 

Fitur Inti Sistem Operasi Solaris ...............53 

Proses Pengembangan dan Metode Penulisan Kode...54 

Tinjauan .......................................60 

FireEngine......................................61 

Sinkronisasi .................................62 

TCP, IP, dan UDP..............................63 

GLDv3.........................................64 

Virtualisasi..................................65 

Least Privilege (Hak Istimewa Terbatas).........66 

Filtrasi Paket..................................67 

Filter IP.....................................68 

Mengaktifkan Filtrasi Paket Sederhana.........69 

Beberapa Contoh Kaidah Filtrasi Paket.........70 

Zona (Zones)....................................73 

Zona Bertanda-identitas (Branded Zones - BrandZ) 

................................................76 

Jaringan Didalam Zona...........................79 

Identitas Zona, Akses terhadap CPU dan Instalasi 

Paket.........................................81 

Perangkat Didalam Zones.......................82 

Prakiraan Penyembuhan-Diri (Predictive Self- 

Healing)........................................83 

Arsitektur Manajemen Kegagalan (Fault Management 

Architecture - FMA)...........................84 

Fasilitas Manajemen Layanan (Services Management 

Facility - SMF)...............................86 

Perunut Dinamis (Dynamic Tracing - DTrace)......87 

Pen-debug Modular (Modular Debugger - MDB)......88 

Sistem File ZFS.................................89 



iv

Penggunaan Checksum dan Perbaikan Data........90 

RAID-Z........................................91 

Konsep Pemograman................................92 

Manajemen Proses dan Sistem.....................93 

Pemograman Thread...............................96 

Sinkronisasi..................................99 

Penjadwalan CPU................................101 

Tinjauan Umum Kernel...........................105 

Perbedaan Antara Eksekusi Modul Kernel dan 

Program Pengguna.............................106 

Perbedaan Struktural antara Modul Kernel Modules 

dan Program Pengguna.........................108 

Men-debug Proses...............................110 

Memulai Penggunaan DTrace.......................112 

Mengaktifkan Probe DTrace Sederhana............113 

Menampilkan Probe Perunut......................116 

Pemograman Bahasa D............................120 

Men-debug Aplikasi dengan DTrace................124 

Mengaktifkan Probe Didalam Moda Pengguna.......125 

Merunut Aplikasi Dengan DTrace.................126 

Men-debug Aplikasi C++ dengan DTrace............131 

Menggunakan DTrace Untuk Men-debug dan Membuat 

Profil Sebuah Program C++ .....................132 

Manajemen Memori dengan DTrace dan MDB..........147 

Perangkat lunak Untuk Manajemen Memori.........148 

Pengujian Memori Virtual dengan DTrace dan MDB.149 

Men-debug Program Penggerak Perangkat Dengan DTrace 

................................................173 

Memindahkan Program Penggerak smbfs Dari Linux Ke 

Solaris OS.....................................174 



v

Sumber Bacaan Tambahan OpenSolaris..............186 



vi

Tujuan 

1M O D U L 

Apa itu Proyek OpenSolaris? 

Tujuan umum dari pelatihan ini adalah agar peserta 

memperoleh pengetahuan tentang Sistem Operasi 

sebagai bagian dari sistem komputasi dengan 

memanfaatkan kode pemograman Sistem Operasi Solaris 

yang secara bebas bisa diperoleh melalui proyek 

OpenSolaris. 

Tip - Lakukan pendaftaran di Internet melalui situs 

http://get.opensolaris.org, agar secara gratis 

dapat menerima OpenSolaris Starter Kit yang terdiri 

dari materi-materi pelatihan, kode pemograman dan 

piranti untuk pengembangan. 

Di bagian awal peserta diperkenalkan bagaimana 

mengakses kelompok pengguna (user group), situssitus 

dan dokumentasi yang berhubungan dengan 

OpenSolaris sehingga peserta dapat segera mengenal 

komputasi berbasis UNIX. 

Berikutnya disajikan dimana peserta bisa mengakses 

lebih jauh informasi-informasi lain yang 

berhubungan dengan Proyek OpenSolaris seperti kode 

pemograman (source code), komunitas, proyek-proyek 

yang sedang berjalan dan penjelajah kode pemograman 

(source browser). 

Langkah selanjutnya, peserta diperlihatkan 

bagaimana mengkonfigurasi zonas, ZFS, jaringan dan 

beberapa fitur lain. Di bagian akhir, terdapat 

latihan-latihan bagi peserta untuk dapat 



1

mempelajari bagaimana menggunakan DTrace untuk mendebug 

proses, aplikasi, kegagalan halaman memori 

(page faults), dan program penggerak perangkat 

(drivers). 



2


Proyek OpenSolaris diluncurkan pada tanggal 14 Juni 

2005 untuk menghasilkan sebuah upaya membangun 

komunitas dengan menggunakan kode pemograman 

Solaris sebagai langkah awalnya. Proyek ini 

merupakan sebuah tempat dimana upaya pengembangan 

komunitas saling terkait, tempat dimana para 

kontributor dari Sun dan siapa pun dapat 

berkolaborasi demi perkembangan dan kemajuan 

teknologi Sistem Operasi. 

Ketersediaan kode pemograman OpenSolaris dapat 

dimanfaatkan untuk banyak hal antara lain sebagai 

dasar untuk versi mendatang produk Sistem Operasi 

Solaris, proyek-proyek Sistem Operasi lainnya, 

produk pabrikan pihak-ketiga dan distribusidistribusi 

aplikasi yang diminati oleh komunitas. 

Hingga saat ini, Sun Microsystems, Inc. yang 

mensponsori proyek ini. 

Hingga 2 tahun pertama, lebih dari 60.000 peserta 

telah terdaftar sebagai anggota. Komunitas para 

rekayasawan ini terus bertumbuh dan berubah untuk 

memenuhi kebutuhan para pengembang perangkat lunak, 

sistem administrator dan pengguna Sistem Operasi 

Solaris. 

Pembelajaran Sistem Operasi dengan proyek 

OpenSolaris memiliki banyak keuntungan dibandingkan 

pembelajaran instruksional: 

Mendapatkan akses ke kode pemograman dari Sistem 

Operasi Solaris 10 yang revolusioner. 

Mendapatkan akses ke kode pemograman dari Sistem 

Operasi komersial yang digunakan secara luas di 

banyak lingkungan bisnis kecil dan besar. 

Keunggulan perangkat lunak untuk melakukan 

observasi dan debug. 

Dukungan perangkat keras yang meliputi arsitektur 

SPARC, x86 dan x64. 

Kepemimpinan Solaris di lingkungan komputasi 64- 



1


bit. 

Pemanfaatan perangkat lunak tak terbatas secara 

gratis. 

Kode pemograman yang menantang, inovatif, 

lengkap, konsisten, tangguh dan bisa diperoleh 

secara bebas. 

Adanya CommonDevelopment and Distribution License 

(CDDL), sebuah aturan lisensi yang disetujui oleh 

OSI, yang membolehkan pemanfaatan yang bebas 

royaliti, modifikasi dan kegiatan ikutan lainnya 



2

Portal Regional 

Portal Regional 

Komunitas Internationalization and Localization 

sebagian bagian dari Proyek OpenSolaris adalah 

komunitas yang bertugas membantu untuk 

menerjemahkan situs OpenSolaris yang berbahasa 

Inggris kedalam bahasa-bahasa yang lain. Sejauh 

ini, terdapat 8 portal dengan bahasa pengantar 

lokal yang masih terus dikembangkan: 

Portal India – http://in.opensolaris.org 

Portal Cina – http://cn.opensolaris.org 

Portal Jepang – http://jp.opensolaris.org 

Portal Polandia – http://pl.opensolaris.org 

Portal Perancis – http://fr.opensolaris.org 

Portal Brasil – 

http://opensolaris.org/os/project/br 

Portal Spanyol – 

http://opensolaris.org/os/project/es 

Portal berbahasa pengantar Jerman, Rusia, Repulik 

Czech, Spanyol, Korea dan Meksiko masih dalam 

status perencanaan. Kunjungi portal OpenSolaris 

untuk bisa ikut berpartisipasi, atau chat di salah 

satu dari tujuh fasiltas chat OpenSolaris dengan 

menggunakan IRC di irc.freenode.net. Kunjungi 

http://opensolaris.org/os/chat/untuk informasi 

lebih lanjut. 



3

Situs-situs OpenSolaris 

Situs-Situs OpenSolaris 

Untuk mendownload kode pemograman OpenSolaris, 

membaca lisensi dan mengakses petunjuk bagaimana 

mengkonstruksi kode pemograman (building source) 

dan menginstal salinan file-file biner prakonstruksi 

yang terkompresi (arsip prakonstruksi/pre-built 

archive) kunjungi situs: 

http://www.opensolaris.org/os/downloads. 

Ikon-ikon di kanan-atas halaman situs OpenSolaris 

menyediakan akses ke halaman diskusi, komunitas, 

proyek, download, dan penjelajah kode pemograman. 

Selain itu, situs OpenSolaris juga tersedia 

fasilitas pencarian isi situs dan kumpulan blog. 



4


Diskusi 

Halaman Diskusi menyediakan akses untuk 

berkomunikasi dengan para ahli yang berkecimpung 

dengan teknlogi kode pemograman terbuka (open 

source). Halaman Diskusi juga menyediakan pencarian 

arsip dari diskusi-diskusi yang pernah dilakukan 

sebelumnya untuk topik tertentu. 

Kunjungi http://www.opensolaris.org/os/discussions 

untuk mendapatkan daftar lengkap forum yang akan 

dipilih untuk berlangganan. 



5


Komunitas 

Halaman komunitas merupakan tempat dimana 

pengunjung dengan minat tertentu yang sama terhadap 

proyek OpenSolaris bisa saling terhubung. Halaman 

komunitas merupakan gabungan dari kelompok peminat 

teknologi, dukungan, piranti, and kelompok 

pengguna: 

Lembaga Akademik dan Penelitian: 

http://www.opensolaris.org/os/community/edu 

DTrace: http:// 

www.opensolaris.org/os/community/dtrace 

ZFS: 

http://www.opensolaris.org/os/community/zfs 

Jaringan: 

http://www.opensolaris.org/os/community/networkin 

g 

Zona: 

http://www.opensolaris.org/os/community/zones 

Dokumentasi: 

http://www.opensolaris.org/os/community/documenta 

tion 

Penggerak Perangkat: http://www.opensolaris.org/ 

os/community/device_drivers 



6


Piranti: 

http://www.opensolaris.org/os/community/tools 

Advokasi: 

http://www.opensolaris.org/os/community/advocacy 

Keamanan: 

http://www.opensolaris.org/os/community/security 

Kinerja: 

http://www.opensolaris.org/os/community/performan 

ce 

Penyimpan Data: 

http://www.opensolaris.org/os/community/storage 

Administrasi Sistem: 

http://www.opensolaris.org/os/community/sysadmin 

Terdapat sekitas 30 komunitas yang berjalan secara 

aktif di OpenSolaris. Kunjungi 

http://www.opensolaris.org/os/communities untuk 

informasi lengkap. 



7


Proyek 

Proyek-proyek yang ada di situs 

http://www.opensolaris.org/ merupakan upaya 

kerjasama yang menghasilkan obyek seperti perubahan 

kode pemograman, dokumen, grafik atau produk 

gabungan berapa pengembang perangkat lunak. Proyek 

memiliki repositori dan komisi yang menguji dan 

menyetujui kode pemograman. Proyek bisa berasal 

dari komunitas atau berdiri sendiri di luar 

komunitas. 

Proyek baru diajukan oleh para peminatnya dengan 

mengajukan permintaan melalui fasilitas diskusi. 

Proyek yang diajukan dan diterima oleh setidaknya 

satu peminat lain di dalam komunitas yang 

mensposorinya akan disediakan ruang untuk halaman 

proyek sehingga proyek dapat dimulai. Kunjungi 

http://www.opensolaris.org/os/projects untuk 

melihat daftar proyek-proyek yang sedang berjalan. 

Piranti Visualisasi Harmonik untuk DTrace : 

http://www.opensolaris.org/ os/project/dtracechime 

Kode Google Summer: 

http://www.opensolaris.org/os/project/powerPC 

Indiana: 

http://www.opensolaris.org/os/project/indiana 

OpenGrok: 

http://www.opensolaris.org/ os/project/opengrok 

Kontes Pemograman: 

http://www.opensolaris.org/os/project/contest 

Starter Kit: 

http://www.opensolaris.org/ os/project/starterkit 

Solaris iSCSI Target: 

http://www.opensolaris.org/ os/project/iscsitgt 



8


Repositori Kode Pemograman 

Repositori kode pemograman yang terpusat dan 

terdistribusi tersedia di situs opensolaris.org. 

Model manajemen kode pemograman terpusat ini 

menggunakan program manajemen yang disebut 

Subversion (SVN) source control. Sedangkan 

manajemen repositori terdistribusi menggunakan 

program manajemen yang disebut kontrol kode 

pemograman Mercurial (hg). 

Pembuatan repositori kode pemograman di 

opensolaris.org dilakukan oleh Pemimpin Proyek di 

halaman proyek yang bersangkutan. Pengembang dengan 

hak commit bisa mengakses repositori dengan 

menggunakan akun yang terdaftar di opensolaris.org. 

Hak commit sendiri diatur oleh Pemimpin Proyek. 

Untuk mengakses repositori dengan hak commit selain 

memiliki akun juga diperlukan kunci publik Secure 

Shell (SSH). Akun bisa diperoleh setelah melakukan 

pendaftaran terlebih dahulu. Kunjungi halaman 

komunitas piranti di 

http://opensolaris.org/os/community/tools untuk 

mendapat informasi terbaru tentang kontrol terhadap 

kode pemograman, download dan petunjuk-petunjuk 

lainya. 



9


OpenGrok 

OpenGrok TM adalah mesin pencari kode pemograman dan 

referensi silang yang cepat dan praktis yang 

digunakan oleh OpenSolaris. Kunjungi 

http://cvs.opensolaris.org/sourceuntuk mencobanya. 

OpenGrok adalah proyek yang pertama kali ada di 

opensolaris.org. Kunjungi 

http://www.opensolaris.org/os/project/opengrok 

untuk mengetahui perkembangan lanjutan proyek ini. 

Coba gunakan perangkat lunak ini dan temukan begitu 

rapinya kode pemograman tertulis, penuh dengan 

deskripsi seolah seperti membaca sebuah buku. Jika 

tertarik berpartisipasi mengembangkan proyek 

OpenSolaris, silakan mendownload kode pemograman 

lengkapnya. Jika hanya sekedar ingin mengetahui 

cara kerja fitur tertentu Solaris, piranti 

alternatif lebih nyaman digunakan adalah penjelajah 

kode pemograman. 

OpenGrok memahami berbagai format file program dan 

version control history seperti SCCS, RCS, and CVS 

sehingga memudahkan pemahaman terhadap prinsipprinsip 

kode pemograman terbuka. 



10

Tujuan 

2M O D U L 

Advokasi OpenSolaris 

Keberadaan Komunitas Advokat bertujuan untuk 

membantu berbagai kalangan dari penjuru dunia untuk 

ikut berpartisipasi dalam Komunitas OpenSolaris. 

Komunitas ini terbuka bagi semua orang dari semua 

bahasa dan kebudayaan dan mereka dengan latar 

belakang teknis ataupun tidak. Setiap orang 

memiliki sesuatu untuk ikut berkontribusi. 

Kunjungi 

http://opensolaris.org/os/community/advocacy/ 

Di dalam komunitas Advokat bisa ditemui proyekproyek 

dari kelompok pengguna yang berdiri sendiri, 

presentasi, berita, artikel, blog, halaman yang 

berisi informasi teknis & non-teknis, video dan 

podcast, seminar dan konferensi. Tersedia juga 

berbagai proyek untuk keperluan promosi seperti 

atribut komunitas, pernak-pernik, lencana, pin dan 

lain-lain. 



11

Mengapa Menggunakan OpenSolaris? 


Bagian ini menjelaskan alasan-alasan praktis yang 

menjadi pertimbangan pemilihan OpenSolaris sebagai 

platform pengembangan perangkat lunak. 



12


Harga 

Popularitas Sistem Operasi Solaris 10 meledak sejak 

ketersediaannya di bulan Januari 2005. Hingga Juli 

2007, sudah terdaftar lebih dari 8.7 juta salinan, 

ini jauh lebih besar dibandingkan gabungan versiversi 

Solaris sebelumnya. Kondisi ini makin terpicu 

dengan diluncurkannya OpenSolaris pada bulan Juni 

2005. Lonjakan luar biasa jumlah pengguna Solaris 

ini, membuat semakin banyak pengembang perangkat 

lunak (komersial atau kode pemograman terbuka) 

melirik Sistem Operasi Solaris sebagai sasaran yang 

berkelanjutan bagi perangkat lunak mereka. 

Salah satu alasan Sistem Operasi Solaris mengalami 

percepatan popularitas yang luar biasa adalah 

karena harganya: $ 0 untuk setiap orang, 

pemanfaatan apa pun (komersial atau non-komersial), 

di semua platform (SPARC atau x86). Alasan lain 

adalah jaminan Sun (dan Sun melaksanakan jaminan 

ini) untuk membuat kode pemograman OpenSolaris 

tersedia bagi publik dibawah lisensi 

CommonDevelopment and Distribution License (CDDL). 

CDDL sendiri adalah sebuah pengaturan lisensi kode 

pemograman terbuka yang telah mendapat persetujuan 

OSI. 



13


Fitur-fitur Inti Yang Inovatif 

Sebenarnya, alasan terpenting bagi naik popularitas 

Solaris adalah kekayaan tak terbatas dari fiturfitur 

yang ditawarkannya. Fitur-fitur tersebut 

adalah: 

Zona Solaris – Menawarkan kemampuan untuk 

mempartisi sebuah komputer menjadi beberapa 

sistem komputasi virtual, yang masing-masing 

saling terisolasi. 

DTrace – Sebuah perangkat perunut (tracing) yang 

dinamis dan komprehensif untuk menginvestigasi 

perilaku system dan aman untuk digunakan 

lingkungan produksi 

Tumpukan IP (IP stacks) Baru – Menyediakan 

peningkatan kinerja yang luar biasa 

ZFS – Sebuah pencapaian tertinggi bagi sistem 

file 128 bit, dengan deteksi dan koreksi 

kesalahan end-to-end, antar muka perintah-baris 

yang sederhana dan secara virtual kapasitas 

penyimpan yang tidak terbatas. 



14


Kompatibilitas Balik 

Semua fitur-fitur baru ini di kembangkan di atas 

platform yang telah lama dinantikan oleh para 

pengguna Sistem Operasi Solaris dengan 

karakteristik: stabilitas yang tangguh, 

skalabilitas yang besar, kinerja tinggi, dan 

jaminan kompatibilitas balik. Kompatibilitas balik 

merupakan hal penting terutama bagi pengembang 

perangkat lunak komersial karena menjaga 

kontinuitas perangkat lunak memerlukan biaya 

tinggi. Dengan jaminan kompatibilitas balik, 

pabrikan perangkat lunak mengetahui bahwa perangkat 

lunak (dengan menggunakan API yang dirilis) yang 

dibuat untuk Solaris ke-N akan berjalan mulus di 

Solaris ke-N+1 dan versi-versi berikutnya. 

Berbeda dengan beberapa Sistem Operasi lain, dimana 

perubahan-perubahan yang tidak kompatibel pada 

komponen sistem – misalnya, libraries – dibuat 

tanpa mempertimbankan efek samping pada applikasi. 

Efek keseluruhan adalah kerusakan aplikasi yang 

menyebabkan tinggi biaya untuk menjaga kontinuitas 

perangkat lunak dan rasa frustasi bagi pabrikan dan 

pengguna. 



15


Netralitas Platform Perangkat Keras 

Paragraf sebelumnya menjelaskan beberapa alasan 

mengapa kita seharusnya mengembangkan Sistem 

Operasi Solaris, tetapi masih ada alasan-alasan 

lain untuk melakukan pengembangkan platform 

Solaris. Salah satunya adalah bahwa Solaris adalah 

Sistem Operasi multi-platform, mendukung baik 

arsitektur SPARC dan x86 (sebuah port ke Power yang 

dimotori oleh sebuah komunitas masih berjalan). 

Meskipun dulu beberapa tahun yang lalu muncul 

keraguan berkaitan Solaris untuk platform x86, pada 

kenyataanya sekarang Sun telah memperkenalkan 

jajaran server dan workstation berbasis AMD yang 

membuktikan kesungguhan Sun terhadap teknologi x86. 

Dari sudut pandang para pengembang perangkat lunak, 

versi Solaris untuk platform SPARC dan x85 memilki 

himpunan fitur dan API yang sama. Ini artinya para 

pengembang dapat lebih berkonsentrai dengan isu-isu 

lain untuk memperluas pengembangan antar-platform, 

seperti CPU endianness. 

Platform SPARC adalah big-endian dan x86 adalah 

little-endian sehingga sebuah aplikasi yang 

dikembangkan dan ditest diatas platform Solaris 

memiliki kemungkinan besar untuk terbebas masalah 

yang berhubungan endian. Solaris juga mendukung 

aplikasi 32 bit dan 64 bits di kedua platform 

tersebut, sehingga membantui menghilangkan bugs 

akibat asumsi-asumsi sekitar ukuran word. 

Mungkin alasan yang paling tak terbantahkan untuk 

mengembangkan perangkat lunak di Solaris adalah 

tersedianya piranti pengembangan perangkat lunak 

yang profesional. 



16


Piranti Pengembangan 

Salah satu fitur terpenting sebuah Sistem Operasi 

dari sudut pandang pengembang perangkat lunak 

adalah tersedianya piranti pengembang perangkat 

lunak yang beragam dan berkualitas. 

Pengkompilasi/Compiler dan pen-debug/debugger 

adalah contoh yang paling lazim dari piranti 

seperti ini, selain pengetest kode pemograman/code 

checkers (untuk memastikan kode pemograman terbebas 

dari kesalahan yang tidak bisa ditemukan oleh 

compiler), pembangkit referensi-silang/crossreference 

generators (untuk melihat fungsi mana 

yang mereferesensi ke fungsi lain atau), dan 

penganalisa kinerja/performance analyzers. 

Sun Studio telah menjadi produk plihan bagi 

pengembang Solaris. Tersedia untuk diunduh secara 

gratis dari situs http://developers.sun.com, 

perangkat lunak Sun Studio adalah gabungan dari 

pengkompilasi dan piranti lain yang berkualitas 

profesional. Lengkapnya terdiri dari pengkompilasi 

C, C++, and FORTRAN; piranti penganalisa kode 

pemograman; sebuah antar muka lingkungan 

pengembangan terintegrasi (integrated development 

environment, IDE); dbx sebuah pen-debug di tingkat 

kode pemograman; dan program pengolah teks 

(editors). 

Piranti lain yang tergabung dalam Sun Studio adalah 

cscope (penjelajah kode pemograman interaktif), ctrace 

(piranti untuk membangkitkan self-tracing version 

dari sebuah program), cxref (program pembangkit 

referensi-silang C), dmake (program bantu untuk 

mengkonstruksi kode pemograman secara paralel dan 

terdistribusi), and lint (pemeriksa program C). 

Solaris dilengkapi dengan pengkompilasi GNU C , gcc, 

and pelengkap berupa pen-debug di tingkat kode 

pemograman, gdb. Solaris juga dilengkapi dengan pen- 



17


debug modular yang sangat berguna, mdb. Namun, mdb 

bukan pen-debug di tingkat kode pemograman. Piranti 

ini sangat berguna untuk men-debug kode kernel, 

atau melakukan analisa gejala tertentu yang 

mengikuti sebuah peristiwa pada sebuah program yang 

biasanya tidak tersedia pada level kode pemograman. 

Informasi lebih lengkap tentang mdb tersedia di buku 

Solaris Modular Debugger Guide and Solaris 

Performance and Tools yang ditulis oleh McDougall, 

Mauro dan Gregg. 



18

Pernyataan Tanda Terima Kasih 

Pernyatan Tanda Terima Kasih 

Anggota-anggota Komunitas OpenSolaris berikut ini 

telah mengevaluasi dan memberikan saran perbaikan 

untuk dokumen ini: 

Boyd Adamson 

PradhapDevarajan 

Alan Coopersmith 

Brian Gupta 

RainerHeilke 

Eric Lowe 

Ben Rockwood 

Cindy Swearingen 

Anggota-anggota Komunitas OpenSolaris berikut ini 

telah menyumbangkan materi baru yang luar biasa: 

Dong-HaiHan 

Narayana Janga 

Shivani Khosa 

Rich Teer 

Sunay Tripathi 

Yifan Xu 

Ucapan terima kasih juga kepada Steven Cogorno, 

David Comay, Teresa Giacomini, StephenHahn, Patrick 

Finch, and Sue Weber atas kerja kerasnya yang 

memungkinkan lahirnya versi awal dokumen ini. 

Untuk berpartisipasi melakukan evaluasi mendatang 

terhadap dokumen ini, lakukan instruksi-instruksi 

seperti terdapat di situs: 

http://www.opensolaris.org/os/community/documentati 

on/reviews 



19

Tujuan 

3M O D U L 

Mempersiapkan Lingkungan 

Kerja OpenSolaris 

Tujuan dari modul ini adalah agar peserta memahami 

kebutuah sistem, informasi pendukung, dokumentasi 

yang tersedia ketika melakukan instalasi dan 

konfigurasi proyek OpenSolaris. 

Sumber Bacaan 

Lain 

Solaris Express Developer Edition Installation 

Guide: Laptop Installations. Sun Microsystems, 

Inc., 2007. 

Sumber Bacaan untuk menjalankan Solaris OS di 

laptop: 

http://www.sun.com/bigadmin/features/articles/lap 

top_resources.html 

Komunitas Laptop OpenSolaris: 

http://opensolaris.org/os/community/laptop 

OpenSolaris Starter Kit: 

http://opensolaris.org/os/project/starterkit 

System Administration Guide: IP Services, 

SunMicrosystems, Inc., 2007 

Komunitas Jaringan OpenSolaris: 

http://www.opensolaris.org/os/community/networkin 

g 



20

Administrasi ZFS dan halaman manual: 

http://opensolaris.org/os/community/zfs/docs 



21

Konfigurasi Perangkat Keras dan Perangkat Lunak 

Konfigurasi Perangkat Keras dan 

Perangkat Lunak 

Mendapatkan pengalaman praktis secara langsung 

untuk mempelajari kode pemograman Sistem Operasi 

dan akses langsung modul-modul kernel merupakan hal 

yang tidak tergantikan. Bagaimana memenuhi 

tantangan unik pengembangan kernel dan mendapatkan 

hak akses root ke sebuah sistem telah dibuat lebih 

mudah oleh piranti, forum dan dokumentasi yang 

disediakan oleh proyek OpenSolaris. 

Tip - Lakukan pendaftaran di Internet melalui situs 

http://get.opensolaris.org, agar secara gratis 

dapat menerima OpenSolaris Starter Kit yang terdiri 

dari materi-materi pelatihan, kode pemograman dan 

piranti untuk pengembangan. 

Pertimbangkan fitur-fitur OpenSolaris berikut ini 

ketika mempersiapkan perangkat keras dan perangkat 

lunak: 

Tabel 3-1 Konfigurasi Pendukung Komponen Lab 

Komponen Dukungan Dari Proyek OpenSolaris 

Perangkat 

Keras 

File Kode 

Pemograman 

Instalasi 

Sistem 

OpenSolaris mendukung sistem dengan 

jajaran prosesor berarstitektur SPARC dan 

x86: UltraSPARC®, SPARC64, AMD64, Pentium, 

and Xeon EM64T. 

Daftar sistem yang didukung, bisa 

didapatkan pada Solaris OS Hardware 

Compatibility List di 

http://www.sun.com/bigadmin/hcl 

Kunjungi 

http://opensolaris.org/os/downloads untuk 

instruksi lengkap bagaiman mengkonstruksi 

kode pemograman 

Distibusi Pre-built OpenSolaris hanya 

dapat digunakan di Solaris Express: 



22


Operasi Community Edition [DVD Version], Build 32 

atau lebih, Solaris Express: Developer 

Edition, Nexenta, Schillix, Martux and 

Belenix. 

Untuk kernel OpenSolaris kernel dengan 

lingkungan pengguna GNU, tersedia di 

http://www.gnusolaris.org/gswiki/Downloadform 

Tabel 3-1 Konfigurasi Pendukung Komponen Lab 

(Lanjutan) 

Komponen Dukungan Dari Proyek OpenSolaris 

BFU 

File on-bfu-DATE.PLATFORM.tar.bz2 tersedia jika ingin men 

archives dari arsip pra-konstruksi. 

Build tools File SUNWonbld-DATE.PLATFORM.tar.bz2 tersedia jika akan 

mengkonstruksi dari kode pemograman sumbernya. 

Compilers Pengkompilasi dan piranti lain Sun Studio 11 terse 

and tools digunakan secara bebas oleh pengembang OpenSolaris 

http://www.opensolaris.org/os/community/tools/sun_ 

untuk instruksi bagaimana mengunduh dan menginstal 

terbarunya. Untuk komunitas gcc, kunjungi 

http://www.opensolaris.org/os/community/tools/gcc 

Kebutuhan Kebutuhan Memori: 256M minimum (mode teks instal 

Memori/Disk 

1GB direkomendasikan 

Lingkungan 

OS Virtual 

Kebutuhan Memory : 768M minimum untuk instalasi 

Express Developer Edition 

Kebutuhan ruang Disk: 350M bytes 

Zona and Zona Bertanda-identitas di OpenSolaris me 

lingkungan Sistem Operasi yang virtual dan terlind 

sebuah instan Solaris. Ini memungkinkan satu atau 

berjalan secara terisolasi dari aktifitas proses y 

system. 

Open Solaris mendukung XEN, sebuah pemonitor syste 

virtual dari komunitas kode pemograman terbuka yan 

dikembangkan oleh tim XEN dari Laboratorium Komput 

Universitas Cambridge. Kunjungi 

http://www.opensolaris.org/os/community/xen/ untuk 

informasi lebih lanjut tentang proyek XEN. 



23


OpenSolaris juga dapat diinstall dalam lingkungan 

kunjungi http://www.opensolaris.org/os/project/con 

mendapat artikel terbaru bagaimana melakukannya. 



24


Lihat di Modul 4 untuk informasi lebih lanjut 

bagaimana Zona and Zona Bertanda-identitas 

memungkinkan pengembangan Solaris kernel atau user 

mode dan aplikasi Linux dapat dilakukan tanpa 

mempengaruhi pengembang yang bekerja di zona yang 

terpisah. 

Dengan berpartisipasi menggunakan proyek 

OpenSolaris akan memperbaiki kinerja keseluruhan 

sistem dan jaringan dengan teknologi terbaru. 

Lingkungan lab menjadi lebih menguntungkan dengan 

menggunakan OpenSolaris karena sistem selalu berada 

di lingkungan komputasi termutakhir dan luar biasa. 



25


Jaringan 

Proyek OpenSolaris memenuhi tantangan masa depan 

teknologi jaringan dengan secara radikal 

memperbaiki performa jaringan tanpa memerlukan 

perubahan-perubahan terhadap aplikasi yang sudah 

ada. 

Kenaikan kinerja aplikasi hingga 50% dengan 

melakukan perbaikan lapisan TCP/IP 

Dukungan terhadap banyak teknologi jaringan 

mutakhir, seperti 10 Gigabit Ethernet, jaringan 

nir-kabel dan hardware offloading 

Mengakomodasi fitur jaringan seperti highavailability, 

streaming, and Voice over IP (VoIP) 

melalui dukungan extended routing dan protocol. 

Dukungan terhadap spesifikasi IPv6 terbaru. 

Informasi lebih lanjut tentang pengembangan 

teknologi jaringan di komunitas OpenSolaris dapat 

dilihat di: 

http://www.opensolaris.org/os/community/networking. 



26

Daemon Auto-Configuration Jaringan 

Daemon Auto-Configuration Jaringan 

Proses boot pada rilis Solaris Express Developer 

Edition 5/07 menjalankan sebuah daemon baru, 

disebut nwamd. Daemon ini merupakan instan 

alternatif dari layanan SMF, svc:/network/physical, yang 

memungkinkan pengkonfigurasian jaringan secara 

otomatis dengan intervensi minimal. 

Daemon nwamd memonitor port Ethernet dan secara 

otomatis mengkonfigurasi kartu jaringan dengan 

DHCP. Jika kabel Ethernet tidak terpasang ke 

jaringan kabel, daemon nwamd melakukan pemindaian 

jaringan nirkabel dan mengirimkan permintaan untuk 

terhubung dengan titik akses WiFi. 

Tidak perlu lagi membuang banyak waktu untuk 

mengkonfigurasi kartu jaringan Ethernet secara 

manual. Konfigurasi otomatis juga sangat 

mempermudah administrasi karena pengkonfigurasianulang 

alamat-alamat jaringan bisa dilakukan dengan 

intervensi minimal. 

Untuk melihat status NWAM, ketikan perintah berikut 

di jendela terminal. 

# svcs nwam 

STATE STIME FMRI 

online 11:29:50 svc:/network/physical:nwam 

Di halaman Network Auto-Magic Phase 0 pada situs 

OpenSolaris dan manual nwamd terdapat keterangan 

lebih rinci, termasuk bagaimana mematikan mematikan 

nwamd. Untuk informasi lebih jauh dan link ke 

halaman manual nwamd(1M), kunjungi 

http://www.opensolaris.org/os/project/nwam. 



27

Tinjauan Umum Zone 

Tinjauan Umum Zona 

Zona dapat dibayangkan seperti sebuah wadah dimana 

didalamnya satu atau lebih aplikasi berjalan secara 

terisolasi dari semua aplikasi yang ada di sistem. 

Semua perangkat lunak yang berjalan di OpenSolaris 

bisa berjalan, tanpa dimodifikasi, didalam zona. 

Karena zona tidak tidak mengubah OpenSolaris 

Application Programming Interface (APIs) or 

Application Binary Interface (ABI) maka aplikasi 

tidak perlu dikompilasi ulang agar bisa berjalan 

didalam zona. 



28

Administrasi Zone 

Administrasi Zona 

Administrasi zona terdiri dari perintah-perintah 

berikut: 

zonecfg – Membuat zona, mengkonfigurasi zona 

(menambah sumber daya dan properti), menyimpan 

konfigurasi zona didalam per-zona file XML yang 

ada di /etc/zones. 

zoneadm – Melakukan langkah-langkah administratif 

untuk zona seperti: menampilkan, menginstal, 

(re)boot dan halt. 

zlogin – Memungkinkan pengguna log in kedalam zona 

untuk melakukan tugas-tugas administrasi. 

zonename – Menampilkan nama zona dimana user 

berada. 

Berikut adalah properti-properti dengan lingkup 

global yang digunakan dengan didalam konfigurasi 

zona: 

zonepath – Lokasi direktori didalam zona global 

yang menjadi direktori root dimana zona akan 

diinstall 

autoboot – Menentukan apakah sebuah zona ikut boot 

atau tidak ketika zona global boot 

pool – Menentukan pool sumber daya yang diberikan 

untuk sebuah zona 

Sumber Daya dapat digolongkan sebagai berikut: 

fs – sistem file 

Inherit-pkg-dir – Direktori-direktori didalam zona 

yang memiliki keterterkaitan dengan paket yang 

berasal dari zona global 



29

Administrasi Zone 

net – Perangkat jaringan 

device – Perangkat-perangkat 

 



30

Memulai Administrasi Zone 

Memulai Administrasi Zona 

Pada latihan lab berikut diperkenalkan proses 

pembuatan zona. 

Ringkasan 

Latihan berikut, menggunakan contoh-contoh yang 

rinci sehingga diharapkan mempercepat pemahaman 

proses pembuatan, instalasi dan boot zona. 

Catatan – Prosedur berikut tidak dapat digunakan 

untuk zona dengan atribut lx (BrandZ) 



31


Membuat, Menginstal dan Boot 

Zona 

1.Gunakan perintah berikut ini untuk 

mengkonfigurasikan sebuah zona baru: 

Catatan – Contoh di bawah ini menggunakan tumpukan 

IP-berbagi, ini adalah standar untuk sebuah zona. 

# zonecfg -z Apache 

Apache: No such zone configured 

Use ’create’ to begin configuring a new zone. 

zonecfg:Apache> create 

zonecfg:Apache> set zonepath=/export/home/Apache 

zonecfg:Apache> add net 

zonecfg:Apache:net> set address=192.168.0.50 

zonecfg:Apache:net> set physical=bge0 

zonecfg:Apache:net> end 

zonecfg:Apache> verify 

zonecfg:Apache> commit 

zonecfg:Apache> exit 

2.Gunakan perintah berikut ini untuk menginstall 

dan boot zona yang telah terkonfigurasikan: 

# zoneadm -z Apache install 

Preparing to install zone . 

Creating list of files to copy from the global zone. 

Copying files to the zone. 

Initializing zone product registry. 

Determining zone package initialization order. 

Preparing to initialize packages on the zone. 

Initialized packages on zone. 

Zone is initialized. 

Installation of these packages generated warnings: .... 

The file 

 

contains a log of the zone installation. 

The necessary directories are created. The zone is ready for 

booting. 



32


3.Lihat isi root direktori-nya: 

# ls /export/home/Apache/root 

bin etc home mnt platform sbin 

tmp var dev export lib opt 

proc system usr 

Paket-paket berikut tidak diinstall-ulang. 

# /etc/mount 

/export/home/Apache/root/lib on /lib read only 

/export/home/Apache/root/platform on /platform read only 

/export/home/Apache/root/sbin on /sbin read only 

/export/home/Apache/root/usr on /usr read only 

/export/home/Apache/root/proc on proc 

read/write/setuid/nodevices/zone=Apache 

4.Boot zona-nya. 

# ifconfig -a 

lo0: 

flags=2001000849 

mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 

bge0: 

flags=1004803 mtu 1500 index 2 

inet 192.168.0.4 netmask ffffff00 broadcast 192.168.0.255 

ether 0:c0:9f:61:88:c9 

# zoneadm -z Apache boot 

# ifconfig -a 

lo0: 

flags=2001000849 

mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 

lo0:1: 

flags=2001000849 

mtu 8232 index 1 zone Apache inet 127.0.0.1 

bge0: flags=1004803 inet 192.168.0.4 netmask ffffff00 broadcast 

192.168.0.255 ether 0:c0:9f:61:88:c9 

bge0:1: flags=1000803mtu 1500 index 2 zone Apache inet 

192.168.0.50 netmask ffffff00 broadcast 192.168.0.255 



33


5.Buat konfigurasi zona dan login: 

# zlogin -C Apache 

[Connected to zone ’Apache’ pts/5] 

# ifconfig -a 

lo0:2: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1 

netmask ff000000 

bge0:2: flags=1000803 inet 192.168.0.50 netmask ffffff00 

broadcast 192.168.0.255 

# ping -s 192.168.0.50 

64 bytes from 192.168.0.50: icmp_seq=0. time=0.146 ms 

# exit 

[Connection to zone ’Apache’ pts/5 closed] 



34

Virtualisasi Server Web dengan Zone 

Virtualisasi Server Web dengan Zona 

Setiap zona memiliki karakteristik tersendiri, 

contohnya, nama zona, alamat IP, nama komputer, 

naming services, akun root dan non-root. Sesuai 

standarnya, Sistem Operasi berjalan didalam zona 

global. Administrator dapat memvirtualisasikan 

lingkungan eksekusi aplikasi dengan mendifinisikan 

satu satu lebih zona non-global. Layanan-layanan 

jaringan dapat dijalankan untuk membatasi kerusakan 

yang terjadi akibat kejadian serangan keamanan. 

Karena zona diimplementasikan di dalam perangkat 

lunak, zona tidak dibatasi granularitasnya 

berdasarkan batasan-batasan yang didefinisikan oleh 

perangkat keras. Tetapi sebaliknya zona menawarkan 

granularitas sub-CPU. 



35

Pembuatan Zone Non-Global 

Pembuatan Zona Non-Global 

Latihan lab berikut ini mendemostrasikan bagaimana 

membuat dua kelompok pengguna server web yang 

berbeda dalam satu sistem komputer. 

Ringkasan 

Akses secara bersamaan ke kedua server web tersebut 

dikonfigurasikan sedemikan rupa sehingga masingmasing 

server web dan sistem akan terlindungi 

meskipun salah satunya telah mendapat serangan 

keamanan. 



36


Membuat Dua Zona Non- 

Global 

1.Membuat zona non-global Apache1: 

# zonecfg -z Apache1 info 

zonepath: /export/home/Apache1 

autoboot: false 

pool: 

inherit-pkg-dir: dir: /lib 

inherit-pkg-dir: dir: /platform 

inherit-pkg-dir: dir: /sbin 

inherit-pkg-dir: dir: /usr 

net: address: 192.168.0.100/24 

physical: bge0 

2.Membuat zona non-global Apache2: 

# zonecfg -z Apache2 info 

zonepath: /export/home/Apache2 

autoboot: false 

pool: 

inherit-pkg-dir: dir: /lib 

inherit-pkg-dir: dir: /platform 

inherit-pkg-dir: dir: /sbin 

inherit-pkg-dir: dir: /usr 

net: address: 192.168.0.200/24 

physical: bge0 

3.Log in ke Apache1 dan menginstall aplikasinya: 

# zlogin Apache1 

# zonename 

Apache1 

# ls /Apachedir 

apache_1.3.9 apache_1.3.9-i86pc-sun-solaris2.270.tar 

# cd /Apachedir/apache_1.3.9; ./install-bindist.sh /local 

Sekarang server Apache HTTP 1.3.9 sudah 

terinstall. 



37


4.Log in ke Apache2 dan menginstall aplikasinya: 

# zlogin Apache2 

# zonename 

Apache2 

# ls /Apachedir 

httpd-2.0.50 httpd-2.0.50-i386-pc-solaris2.8.tar 

# cd /Apachedir/httpd-2.0.50; ./install-bindist.sh /local 

You now have successfully installed the Apache 2.0.50 HTTP 

server. 

5.Jalankan aplikasi Apache1: 

# zonename 

Apache1 

# hostname 

Apache1zone 

# /local/bin/apachectl start 

/local/bin/apachectl start: httpd started 

6.Jalankan aplikasi Apache2: 

# zonename 

Apache2 

# hostname 

Apache2zone 

# /local/bin/apachectl start 

/local/bin/apachectl start: httpd started 

7.Didalam zona global , edit /etc/hosts file: 

# cat /etc/hosts 

# 

# Internet host table 

# 

127.0.0.1 localhost 

192.168.0.1 loghost 

192.168.0.100 Apache1zone 

192.168.0.200 Apache2zone 



38


8.Buka penjelajah web dan and kunjungi URL berikut: 

http://apache1zone/manual/index.html 

Server web Apache1 aktif dan jalan. 

9.Buka penjelajah web dan and kunjungi URL berikut: 

http://apache2zone/manual/ 

Server web Apache2 aktif dan jalan. 



39


Diskusi 

Pengguna melihat masing-masing zona sebagai sistem 

yang berbeda. Masing-masing server web memiliki 

name services masing-masing: 

File /etc/nsswitch.conf 

File /etc/resolv.conf 

Serangan jahat terhadap server web dibatasi hanya 

terjadi didalam zona. Konflik port juga tidak 

pernah terjadi! 



40

Pembuatan Pool Penyimpan Data dan Sistem File ZFS 

Pembuatan Pool Penyimpan Data dan 

Sistem File ZFS 

Masing-masing pool penyimpan data ZFS terdiri dari 

satu atau lebih perangkat virtual, yang 

menggambarkan susunan fisik penyimpan data dan 

karakteristik penanganan kegagalannya. 

Dalam modul ini, pembahasan dimulai dengan 

mempelajari konfigurasi pool penyimpan data termirror. 

Kemudian, akan diperlihatkan bagaimana 

membuat konfigurasi sebuah pool RAID-Z. 



41

Membuat Storage Pool ZFS Mirrored 

Membuat Pool Penyimpan Data ZFS Termirror 

Tujuan latihan lab ini adalah untuk membuat dan 

menampilkan pool penyimpan data ter-mirror dengan 

perintah zpool. 

Untuk mendapatkan informasi, bagaimana memilih 

antara pool penyimpan data ZFS dengan konfigurasi 

ter-mirror atau RAID-Z yang sesuai dengan 

lingkungan komputasi tertentu, kunjungi: 

http://www.solarisinternals.com/wiki/index.php/ZFS_ 

Best_Practices_Guide 

Ringkasan 

ZFS adalah mudah, mulailah mencobanya! 

Sekarang waktunya membuat pool untuk pertama kali. 

. 



42

Membuat Storage Pool ZFS Mirrored 

Membuat Pool Penyimpan Data Termirror 

1.Buka jendela terminal 

2.Buatlah sebuah pool penyimpan data ter-mirror 

bernama tank. Kemudian tampilkan informasi pool 

penyimpan data tersebut: 

# zpool create tank mirror c1t1d0 c2t2d0 

# zpool status tank 

pool: tank 

state: ONLINE 

scrub: none requested 

config: 

NAME STATE READ WRITE CKSUM 

tank ONLINE 0 0 0 

mirror ONLINE 0 0 0 

c1t1d0 ONLINE 0 0 0 


errors: No known data errors 

Kapasitas disk c1t1d0 dan c2t2d0 masing-masing 

adalah 36 Gbytes each. Karena kedua disk tersebut 

di-mirror, maka kapasitas total pool 

merefleksikan kurang lebih ukuran salah satu 

disknya. Metadata untuk pool menghabiskan ruang 

disk dengan jumlah yang kecil. 

Sebagai contoh: 

# zpool list 

NAME SIZE USED AVAIL CAP HEALTH ALTROOT 

tank 33.8G 89K 33.7G 0% ONLINE – 



43

Membuat Sistem File ZFS Sebagai Direktori Kerja Pengguna 

Membuat Sistem File ZFS Sebagai 

Direktori Kerja Pengguna 

Tujuan dari latihan lab ini adalah untuk 

mempelajari bagaimana membuat sebuah sistem file 

ZFS sebagai beberapa direktori kerja (home 

directory) pengguna. 

Dengan menggunakan fitur sistem file ZFS, yang 

tersedia di proyek OpenSolaris, memungkinkan 

dilakukannya penyederhanaan proses pengembangan 

kernel dengan memanfaatkan fitur snapshots dan 

rollback. 

Ringkasan 

Didalam lab ini, digunakan perintah zfs untuk 

membuat sebuah sistem file ZFS dan menentukan 

direktori aksesnya (mount point). 



44


Membuat Sistem File ZFS Sebagai 

Direktori Kerja Pengguna 

1.Tampilkan file sistem standar yang telah dibuat 

secara otomatis ketika pool penyimpan data 

dibuat. 

# zfs list 

NAME USED AVAIL REFER MOUNTPOINT 

tank 86K 33.2G 24.5K /tank 

2.Buat sistem file tank/home: 

# zfs create tank/home 

3.Kemudian, ubah direktori akses sistem file 

tank/home seperti berikut ini: 

# zfs set mountpoint=/export/home tank/home 

4.Kemudian, buat sistem file – sistem file tank/home 

untuk beberapa pengguna: 

# zfs create tank/home/developer1 




Properti mountpoint akan digunakan secara 

berkelanjutan untuk menentukan awalan nama 

direktori (pathname prefix). Sehingga direktori 

akses tank/home/developer1 secara otomatis akan 

menjadi /export/home/developer1 karena direktori akses 

tank/home telah diubah menjadi /export/home. 

5.Periksa apakah sistem file ZFS telah dibuat: 

# zfs list 


tank 246K 33.2G 26.5K /tank 

tank/home 128K 33.2G 29.5K /export/home 

tank/home/developer1 24.5K 33.2G 24.5K /export/home/developer1 






45




46


Lakukan snapshot secara rekursif untuk sistem file 

tank/home. Kemudian, tampilkan informasi snapshot 

tersebut: 

# zfs snapshot -r tank/home@today 

# zfs list 


tank 252K 33.2G 26.5K /tank 

tank/home 128K 33.2G 29.5K /tank/home 

tank/home@today 0 - 29.5K - 

tank/home/developer1 24.5K 33.2G 24.5K /tank/home/developer1 

tank/home/developer1@today 0 - 24.5K - 







Untuk informasi lebih lanjut, lihat zfs.1m. 



47

Membuat Konfigurasi RAID-Z 


Tujuan dari latihan lab ini adalah sebagai 

pengenalan terhadap konfigurasi RAID-Z. 

Ringkasan 

Konfigurasi RAID-Z dibuat sebagai konfigurasi 

alternatif terhadap konfigurasi pool penyimpan data 

ter-mirror untuk kebutuhan memaksimalkan ruang 

disk. 



48


Membuat Konfigrurasi RAID-Z 

1.Buka jendela terminal. 

2.Buat sebuah pool dengan sebuah perangkat tunggal 

RAID-Z yang terdiri dari 5 disk. Kemudian, 

perlihatkan informasi tentang pool penyimpan data 

tersebut. 

# zpool create tank raidz c1t1d0 c2t2d0 c3t3d0 c4t4d0 c5t5d0 

# zpool status tank 

pool: tank 

state: ONLINE 

scrub: none requested 

config: 

NAME STATE READ WRITE CKSUM 

tank ONLINE 0 0 0 

raidz1 ONLINE 0 0 0 






errors: No known data errors 

Disk bisa diakses dengan nama pendek atau nama 

lengkapnya. Contohnya, /dev/dsk/c4t4d0 adalah identik 

dengan c4t4d0. 

Dimungkinkan juga untuk menggunakan partisi disk 

sebagai pool penyimpan data ter-mirror dan RAID-Z, 

tapi konfigurasi seperti ini tidak direkomendasikan 

untuk lingkungan produksi. Untuk informasi lebih 

lanjut tentang penggunaan ZFS di lingkungan 

produksi, kunjungi: 

http://www.solarisinternals.com/wiki/index.php/ZFS_ 

Best_Practices_Guide. 



49

Tujuan 

4M O D U L 

Konsolidasi Area Pengguna 

Tujuan modul ini adalah untuk memperkenalkan 

konsolidasi area pengguna (userland consolidations) 

dari OpenSolaris. Secara umum, konsolidasi area 

pengguna dapat dianggap sebagai kumpulan perangkat 

lunak yang berada diluar kernel dan sebagai 

komponen dimana denganya pengguna berinteraksi. 

Masing-masing konsolidasi mendistribusikan filefile 

kode pemogramannya ke situs opensolaris.org or 

sentra download Sun. Untuk mengakses masing-masing 

konsolidasi, kunjung URL berikut: 

http://opensolaris.org/os/downloads/. 



50

Konsolidasi Area Pengguna dan Deskripsinya 

Konsolisidasi Area Pengguna dan 

Deskripsinya 

Server Applikasi Server Aplikasi Glassfish 

Piranti Pengembangan 

Produk (DevPro) 

Librari matematika, 

library media, librari 

microtasking, librari 

SCCS, make, dan C++ 

runtime. 

Dokumentasi (Docs) Dokumentasi teknis 

pengembangan dan 

administrasi. 

Dukungan Globalisasi 

(G11N) 

Dukungan Instalasi 

(Install) 

Dukungan 

Internationalisasi and 

lokalisasi. 

Dukungan instalasi and 

piranti pembuat paket. 

Solusi JavaDesktop (JDS). Perangkat lunak desktop 

korporat yang aman dan 

komprehensif. 

Java Platform, Standard 

Edition (Java SE) 

Distribusi 

JavaDevelopment Kit (JDK) 

and Java Runtime 

Environment (JRE). 

Halaman Manual Kode pemograman untuk 

Halaman Manual Referensi 

SunOS. 

Message Queue. Sun Java SystemMessage 

Queue 

Penyimpan Data dalam 

Jaringan (NWS) 

Dukungan perangkat 

penyimpan data dalam 



51

Konsolidasi Area Pengguna dan Deskripsinya 

jaringan. 

SFW (Solaris FreeWare) Perangkat lunak dengan 

kode pemograman terbuka 

yang tersedia di Solaris/ 

OpenSolaris. 

Dukungan Grafik SPARC Konsolidasi grafik SPARC 

memiliki file-file biner 

untuk penggeraknya. 

Test Piranti dan kumpulan 

perangkat lunak pengujian 

OpenSolaris. 

X Window System (X11) Perangkat lunak X11 



52

Tujuan 

5M O D U L 

Fitur Inti Sistem Operasi 

Solaris 

Tujuan dari modul ini adalah untuk memberikan 

gambaran fitur utama dari Solaris dan bagaimana 

fitur-fitur tersebut secarna fundamental telah 

mengubah komputasi Sistem Operasi 

Sumber Bacaan 

Lain 

Proses Pengembangna OpenSolaris; 

http://www.opensolaris.org/os/community/onnv/os_d 

ev_process/ 

Standarisasi C Style dan Penulisan Kode untuk 

SunOS; 

http://www.opensolaris.org/os/community/documenta 

tion/getting_started_docs/ 



53

Proses Pengembangan dan Metode Penulisan Kode 

Proses Pengembangan dan Metode 

Penulisan Kode 

Langkah-langkah proses pengembangan dan metode 

penulisan kode (coding style), yang digunakan oleh 

konsolidasi OS/Net (ON), dibuat untuk 

mendistribusikan komponen utama Sistem Operasi dan 

komponen Jaringan. 

Komponen Operating System and Networking terdiri 

dari kode pemograman kernel untuk semua platform 

(untuk semua arsitektur), sekumpulan kode 

pemograman penggerak perangkat, sistem file, 

librari utama dan perintah dasar yang biasa 

terdapat di sistem Solaris. 

Proses pengembangan proyek OpenSolaris mematuhi 

langkah-langkah umum berikut: 

1.Ide 

Pertama, seseorang yang memiliki sebuah ide untuk 

perbaikan /penambahan atau memiliki 

ketidaknyamanan akibat adanya cacat. Lakukan 

pencarian informasi terlebih dahulu untuk 

kemungkinan keberdaan bug tersebut atau 

mengajukan sebagai kasus bug baru atau meminta 

request for enhancement (RFE) dengan menggunakan 

fasilitas yang ada di halaman 

http://bugs.opensolaris.org/. Berikutnya, 

mengumumkan hal tersebut kepada pengembangpengembang 

lain melalui E-mail list. Penyebaran 

pengumuman ini memiliki keuntungan-keuntungan 

sebagai berikut: 

Memicu dengan segera adanya diskusi untuk 

pengubahan atau perbaikan 

Menentukan kompleksitas dari pengubahanpengubahan 

yang diajukan 



54


Memperkirakan ketertarikan komunitas 

Mengidentikasikan calon anggota tim yang 

potensial 



55


2.Desain 

Fase desain menentukan apakah diperlukan atau 

tidak adanya tinjauan desain secara formal. Jika 

diperlukan tinjauan desain secara formal, maka 

lengkapi langkah-langkah berikut ini: 

Mengidentifikasi peninjau (reviewers) bagi 

desain dan arsitektur yang akan diajukan 

Membuat dokumen desain 

Membuat rencana pengujian 

Melakukan tinjauan desain dan meminta 

persetujuan dengan benar 

3.Implementasi 

Fase implementasi terdiri dari hal-hal berikut: 

Menuliskan kode yang akan menjadi solusi sesuai 

dengan ketentuan dan standar. Unduh Standar C 

Style and Coding untuk SunOS disini: 

http://www.opensolaris.org/os/community/documen 

tation/getting_started_docs/. 

Membuat kumpulan pengujian 

Melewati dan lulus berbagai unit and praintegrasi 

pengujian 

Menuliskan atau memperbaharui dokumentasi 

pengguna, jika diperlukan 

Mengindentifikasi peninjau kode pemograman 

dalam rangka persiapan untuk integrasi 

4.Integrasi 

Integrasi terjadi setelah semua peninjau telah 

menyelesaiakan proses penijauan dan izin untuk 

melakukan integrasi telah diberikan. 

Fase integrasi diperlukan untuk memastikan bahwa 



56


semua prosedur telah dipenuhi; memiliki fakta yang 

lengkap yang artinya telah ditinjau kode 

pemograman-nya, dokumentasi dan kelengkapannya. 



57


Dokumen proses resmi untuk OpenSolaris menjelaskan 

langkah-langkah diatas lebih rinici, disertai 

diagram alir yang mengilustrasikan setiap fase-fase 

pengembangan. Dokumen tersebut juga menjelaskan 

secara rinci prinsip-prinsip desain dan nilai-nilai 

utama yang diterapkan terhadap pengembangan kode 

pemograman untuk proyek OpenSolaris: 

Kehandalan – OpenSolaris harus melakukan 

fungsinya secara benar, menyediakan hasil kerja 

yang akurat tanpa kehilangan data atau 

terkorupsi. 

Ketersediaan – Layanan-layanan harus didisain 

dengan kemampuan distart-ulang jika terjadi 

kegagalan aplikasi dan OpenSolaris sendiri harus 

berkemampuan memulihkan diri dari kegagalan 

perangkat keras yang tidak fatal 

Kemampuan Servis – Kemampuan untuk mendiagnosa 

baik masalah-masalah yang fatal dan transien dan 

jika memungkinkan, mengotomasasi diagnosanya. 

Keamanan – Keamanan OpenSolaris harus didisain 

sebagai bagian dari Sistem Operasi dengan 

menyediakan mekanisme agar dapat melakukan audit 

terhadap perubahan-perubahan yang dilakukan di 

sistem dan siapa yang melakukannya. 

Kinerja – Kinerja OpenSolaris harus yang teratas 

dibandingkan Sistem Operasi lain yang berjalan di 

lingkungan yang sama. 

Kemudahan Manajemen – Manejemen komponen individu 

perangkat keras atau perangkat lunak yang 

konsisten dan cara yang mudah. 

Kompatibilitas – Sub-sistem dan antar-muka baru 

harus bisa diperluas dan dibuatkan versi 

terbarunya agar memungkinkan perbaikan atau 

perubahan di masa mendatang tanpa mengkuatirkan 

kompatibilitas. 



58


Kemudahan Perawatan – OpenSolaris harus 

berarsitektur sedemikian rupa sehingga subrutinsubrutin 

umum dapat dikombinasikan kedalam 

librari atau modul kernel yang kemudian dapat 

digunakan sebanyak-banyaknya pengguna. 

Netralitas Platform –OpenSolaris harus tetap 

netral terhadap semua platform perangkat keras 

dan abstraksi level bawah harus selalu didisain 

dengan pertimbangan sebagai Sistem Operasi untuk 

banyak platform dan platform masa depan. 

Kunjungi 

http://www.opensolaris.org/os/community/onnv/os_dev 

_process/ untuk informasi lebih detail tentang 

bagaimana proses yang digunakan untuk pengembangan 

secara kolektif kode pemograman OpenSolaris. 

Seperti proyek-proyek lainnya, Open Solaris 

mengatur secara ketat metode penulisan kode untuk 

kode pemograman yang didistribusikan, darimana pun 

sumbernya. Hal ini dijelaskan secara rinci di situs 

http://opensolaris.org/os/community/onnv/. 

Ada 2 piranti untuk pengecekan elemen-elemen dari 

metode penulisan kode yang tersedia sebagai bagian 

dari distribusi OpenSolaris. Piranti tersebut 

adalah cstyle(1) untuk melakukan verifikasi kepatuhan 

sebuah kode pemograman terhadap pedoman metode 

penulisan kode umum, dan hdrchk(1) untuk pengecekan 

metode penulisan header C dan C++. 



59

Tinjauan 

Tinjauan 

Setelah mengenal lingkungan pengembangan, tahaptahap 

pengembangan dan prinsip-prinsip yang 

diterapkan oleh pengembang OpenSolaris, berikutnya 

dibahas lebih dalam fitur-fitur Sistem Operasi 

OpenSolaris untuk membuktikan keunggulannya dari 

sisi kinerja, keamanan, kemampuan servis dan 

kemudahan manajemen: 

Kinerja 

FireEngine 

Nemo 

Crossbow 

Keamanan 

Least Privilege 

Packet Filtering 

Zones 

Branded Zones (BrandZ) 

Kemampuan Servis 

Predictive Self-Healing 

Dynamic Tracing Facility (DTrace) 

ModularDebugger (MDB) 

Kemudahan Manajemen 

ServicesManagement Facility (SMF) 

ZFS 



60

Tinjauan 

FireEngine 

Fitur "FireEngine" yang ada di Solaris 10 adalah 

sebuah pendekatan yang menggabungkan semua lapisan 

protokol TCP/IP kedalam satu modul STREAMS yang 

secara penuh multithread. Didalam module yang 

tergabung ini, dibandingkan metode penguncian perstruktur 

data, sebuah mekanisme sinkronisasi per- 

CPU yang disebut “perimeter vertikal” (vertical 

perimeter) digunakan. 

Mekanisme perimeter vertikal diimplementasikan 

dengan menggunakan abstraksi antrian secara serial 

yang disebut "squeue." Masing-masing squeue 

dilekatkan ke sebuah CPU, dan masing-masing koneksi 

secara bergantian dilekatkan ke sebuah squeue yang 

menyediakan metode sinkronisasi dan mutual 

exclusion yang diperlukan oleh struktur data perkoneksi. 



61

Tinjauan 

Sinkronisasi 

Karena lapisan TCP/IP secara penuh adalah 

multithread (dimana hanya serialiasasi per-CPU yang 

dilakukan oleh sebuah perimeter vertikal), metode 

ini menggunakan skema berbasiskan-referensi untuk 

memastikan bahwa instan koneksi selalu tersedia 

ketika diperlukan. Untuk koneksi TCP yang terjadi, 

tiga referensi diberikan kepadanya. 

Masing-masing lapisan protokol memiliki sebuah 

referensi untuk setiap instan koneksi (satu untuk 

lapisan TCP dan satu untuk lapisan IP) dan 

classifier sendiri memiliki satu referensi karena 

classifier berfungsi mewakili setiap koneksi yang 

telah dibuat. Setiap kali sebuah paket datang untuk 

koneksi tertentu dan classifier mencari instan 

koneksinya, sebuah referensi tambahan ditempatkan, 

yang kemudian referensi tersebut dibuang ketika 

lapisan protokol selesai memproses paket tersebut. 



62

Tinjauan 

TCP, IP, dan UDP 

Solaris 10 OS menyediakan sudut pandang yang sama 

terhadap TCP seperti terdapat pada versi-versi 

sebelumnya – yaitu TCP muncul sebagai sebuah 

perangkat terduplikasi (clone device) meskipun 

sebenarnya TCP adalah sebuah gabungan (composite), 

dimana kode TCP and IP dileburkan kedalam satu 

modul D_MP STREAMS. 

Bagian operasional TCP dilindungi secara penuh oleh 

perimeter vertical yang dimasukan melalui primitif 

squeue. FireEngine mengubah antar-muka antara TCP 

dan IP dari antar-muka yang ada sekarang yaitu 

penerusan pesan berbasiskan-STREAMS (STREAMS-based 

message passing) menjadi sebuah antar-muka 

berbasiskan-panggilan fungsional (functional callbased), 

baik untuk pengiriman informasi kontrol dan 

data. 

Terdapat juga modul UDP yang secara penuh 

multithread, yang berjalan dibawah domain 

perlindungan yang sama seperti IP. Meskipun UDP and 

IP berjalan didalam domain perlindungan yang sama, 

keduanya tetap merupakan modul-modul STREAMS yang 

terpisah. Sehingga, penempatan STREAMS secara 

vertikal (STREAMS plumbing) tetap tidak berubah dan 

sebuah instan modul UDP selalu didorong diatas 

modul IP. Platform Solaris 10 menyediakan dua mode 

penempatan secara vertikal (plumb modes) sebagai 

berikut: 

Normal – IP dibuka terlebih dahulu kemudian UDP 

didorong secara langsung diatasnya. Ini adalah 

aksi standar yang terjadi ketika sebuah soket UDP 

atau perangkat dibuka. 

SNMP – UDP didorong diatas modul selain IP. 

Ketika ini terjadi, hanya semantik SNMP yang akan 

didukung. 



63

Tinjauan 

GLDv3 

Solaris 10 memperkenalkan sebuah kerangka kerja 

baru untuk program penggerak perangkat (new device 

driver framework) disebut GLDv3 disertai dengan 

lapisan fungsional baru. Sebagian besar program 

penggerak perangkat utama sudah menggunakan ke 

struktur ini, dan semua program penggerak perangkat 

masa depan dan perangkat jaringan 10 Gb akan 

berdasarkan kerangka ini. Kerangka kerja ini juga 

menyediakan sebuah lapisan DLPI berbasiskan-STREAMS 

untuk kompatibilitas balik, sehingga modul-modul 

ekstenal dan modul non-IP dapat terus bekerja. 

Arsitektur GLDv3 mem-virtulisasikan lapisan kedua 

dari lapisan protokol jaringan. Korespondesi satulawan-satu 

antara antar-muka jaringan dan lapisan 

fungsional perangkat diatasnya tidak diperlukan 

lagi. 

Kunjungi Proyek Nemo di situs opensolaris.org untuk 

informasi lebih lanjut yang berkaitan dengan 

kerangka kerja ini , modul layanan MAC, modul Data- 

Link Services. 



64

Tinjauan 

Virtualisasi 

Proyek Crossbow merupakan sebuah proyek yang 

bertujuan untuk membuat lapisan protokol virtual 

dari semua layanan jaringan (HTTP, HTTPS, FTP, NFS, 

dsb), protokol utama (TCP, UDP, SCTP, dsb.), atau 

Teknologi Kontainer Solaris. 

Lapisan protokol virtual ini dipisahkan berdasarkan 

klasifikasi perangkat keras artinya trafik untuk 

satu lapisan protokol tertentu tidak akan 

mempengaruhi lapisan protokol virtual yang lain. 

Masing-masing lapisan protokol virtual ini dapat 

diberikan prioritas dan lebarpita yang berbeda 

meskipun hanya menggunakan satu kartu Ethernet 

tanpa menimbulkan penurunan kinerja terhadap sistem 

atau layanan/kontainer. 

Aristektur ini secara dinamis mengatur prioritas 

dan alokasi lebar-pita, selain itu juga menyediakan 

pertahanan yang lebih baik terhadap serangan 

denial-of-service yang ditujukan kepada layanan 

atau kontainer tertentu; yaitu dengan pengisolasian 

dampak serangan hanya pada layanan atau kontainer 

tersebut. 



65

Tinjauan 

Least Privilege (Hak Istimewa 

Terbatas) 

Dari sejak dulu, UNIX memiliki model hak istimewa 

didalam sistem yang bersifat “berikan semuanya atau 

tidak sama sekali” (all-or-nothing) yang memaksakan 

pembatasan-pembatasan berikut: 

Hak istimewa root tidak dapat dibatasi 

Pengguna non-root tidak bisa melakukan kegiatan 

administratif terhadap sistem yang memerlukan hak 

istimewa karena tidak cara untuk membagi hak 

istimewa ke pengguna non-root 

Aplikasi yang sebenarnya hanya memerlukan sedikit 

kegiatan dengan hak istimewa harus dijalankan 

sebagai root 

Sangat sedikit hal yang bisa dipercaya dengan 

hak-hak istimewa root dan secara virtual tidak ada 

pengguna non-root yang begitu sangat dipercaya. 

Di dalam Solaris OS telah dikembangkan fine-grained 

privileges. Fine-grained privileges memungkinkan 

aplikasi dan proses login users untuk berjalan 

hanya dengan hak-hak istimewa yang mereka butuhkan. 

Sebagai ilustrasi, hak istimewa terbatas 

memungkinkan mahasiswa untuk diberikan hak-hak 

istimewa terbatas yang mereka butuhkan untuk 

menyelesaikan kuliah mereka, berpartisipasi dalam 

riset dan melakukan perawatan sebagian dari 

infrastruktur kampus atau departemen. 



66

Tinjauan 

Filtrasi Paket 

Solaris IP Filter berfungsi menyediakan stateful 

packet filtering and network address translation 

(NAT). Solaris IP Filter berasal dari perangkat 

lunak kode pemograman terbuka IP Filter. 

IP Filter dapat menyaring paket berdasarkan alamat 

IP, port, protokol, atau antarmuka jaringan 

berdasarkan kaidah-kaidah filter tertentu. 



67

Tinjauan 

Filter IP 

Packet Filtering Hooks (PFHooks) API telah 

diperkenalkan sejak Solaris 10 Update 4, untuk 

menggantikan implementasi berbasiskan-STREAMS dari 

IP Filter. Dengan menggunakan kerangka kerja 

PFHooks, kinerja perangkat lunak firewall seperti 

IP Filter secara luar biasa mengalami peningkatan. 

PFhooks juga menyediakan kemampuan untuk mencegat 

trafik loopback dan inter-zona. Perangkat lunak 

firewall pihak ketiga dikembangkan dan diregistrasi 

dengan PFHooks API menggunakan the 

net_register_hook(info, event, hook); hook. 



68

Tinjauan 

Mengaktifkan Filtrasi Paket 

Sederhana 

Tujuan latihan ini untuk mempelajari filtrasi 

paket. Solaris IP Filter telah terinstall didalam 

Sistem Operasi Solaris, namun, sesuai standarnya 

filtrasi paket tidak diaktifkan. IP Filter dapat 

mem-filter berdasarkan alamat IP, port, protokol, 

atau antar muka jaringan berdasarkan kaidah-kaidah 

filter tertentu. Berikut ini adalah sebuah contoh 

kaidah filter: 

block in on ce0 proto tcp from 192.168.0.0/16 to any port = 23 

Untuk menggunakan Solaris IP Filter, caranya 

sederhana yaitu dengan memasukan kaidah filter 

kedalam file /etc/ipf/ipf.conf. Kemudian, aktifkan dan 

start-ulang layanan svc:network/ipfilter dengan 

perintah svcadm. 

Catatan – Perintah ipf juga dapat digunakan untuk 

membuat kaidah-kaidah IPFilter. 

Solaris IP Filter dapat melakukan juga 

pengkonversian alamat jaringan (NAT, Network 

Address Translation) untuk sebuah alamat IP 

pengirim atau sebuah alamat IP tujuan berdasarkan 

kaidah NAT. Berikut adalah sebuah contoh kaidah 

NAT: 

map ce0 192.168.1.0/24 -> 10.1.0.0/16 

Agar dapat melakukan pengkonversian alamat 

jaringan, simpan kaidah-kaidah NAT kedalam file 

/etc/ipf/ipnat.conf. Kemudian aktifkan dan start-ulang 

layanan svc:/network/ipfilter dengan perintah svcadm. 

Catatan – Perintah ipnat juga dapat digunakan untuk 

membuat kaidah-kaidah NAT. 



69

Tinjauan 

Beberapa Contoh Kaidah Filtrasi 

Paket 

Pada bagian ini diberikan beberapa contoh kaidah 

pembentukan filter. Mengaktifkan kaidah filter 

adalah dengan menambahkanya kedalam file 

/etc/ipf/ipf.conf. Kemudian, aktifkan Solaris IP Filter 

and reboot komputer seperti dijelaskan secara 

detail pada latihan sebelumnya. 

Me-log semua paket masuk di le0 dengan opsi IP 

aktif. 

log in on le0 from any to any with ipopts 

Memblokir semua paket masuk di le0 yang terfragment 

dan terlalu pendek untuk dilakukan perbandingan 

tertentu. Ini sebenarnya hanya bisa diterapkan 

untuk paket TCP yang bisa mengalami kehilangan 

flag/port (tergantung kondisi fragment yang 

terlihat). 

block in log quick on le0 from any to any with short frag 

Me-log semua paket masuk TCP hanya jika bendera SYN 

aktif. 

Catatan – Jika paket masuk TCP memiliki bendera SYN 

yang aktif dan memiliki opsi IP yang aktif maka 

kaidah ini menyebabkan paket di-log sebanyak dua 

kali. 

log in on le0 proto tcp from any to any flags S/SA 



70

Tinjauan 

Memblokir dan me-log semua paket masuk ICMP 

unreachable: 

block in log on le0 proto icmp from any to any icmp-type unreach 

Memblokir dan me-log semua paket masuk UDP di le0 

yang menuju ke port 2049 (portnya NFS): 

block in log on le0 proto udp from any to any port = 2049 

Segera membolehkan semua paket ke/dari sebuah 

pasangan komputer tertentu: 

pass in quick from any to 10.1.3.2/32: 

pass in quick from any to 10.1.0.13/32 

pass in quick from 10.1.3.2/32 to any 

pass in quick from 10.1.0.13/32 to any 

Memblokir (dan berhenti mencari kaidah lain yang 

cocok) semua paket dengan opsi IP aktif: 

block in quick on le0 from any to any with ipopts 

Meneruskan semua paket yang lewat: 

pass in from any to any 



71

Tinjauan 

Memblokir semua paket masuk UDP yang ditujukan ke 

subnet tertentu: 

block in on le0 proto udp from any to 10.1.3.0/24 



Memblokir semua paket masuk TCP jika hanya bendera 

SYN aktif dan ditujukan ke subnet-subnet berikut: 

block in on le0 proto tcp from any to 10.1.3.0/24 flags S/SA 



Memblokir semua paket masuk ICMP yang ditujukan ke 

subnet-subnet berikut: 

block in on le0 proto icmp from any to 10.1.3.0/24 





72

Tinjauan 

Zona (Zones) 

Zona adalah sebuah abstraksi Sistem Operasi virtual 

yang menyediakan lingkungan komputasi terproteksi 

dimana didalamnya aplikasi dapat berjalan. Didalam 

zona, aplikasi tertentu diproteksi dari aplikasi 

lainnya untuk menyediakan isolasi terhadap 

kegagalan perangkat lunak. 

Untuk memudahkan pekerjaan mengontrol banyak 

aplikasi dan lingkunganya, semua aplikasi berjalan 

bersaman dalam satu Sistem Operasi, dan biasanya 

dikontrol sebagai satu unit. 

Sejumlah kecil aplikasi yang biasanya dijalankan 

sebagai root proses atau dengan hak-hak istimewa 

tertentu tidak diperbolehkan untuk berjalan didalam 

zona jika aplikasi-aplikasi tersebut berkemampuan 

mengakses atau mengubah sumber daya global. Sebagai 

contoh, kemampuan untuk mengubah penghitung waktu 

harian sistem. Aplikasi-aplikasi seperti ini 

sebaiknya tetap digunakan hanya didalam zona global 

tetapi jika diperlukan berjalan didalam zona nonglobal 

maka harus dikonfigurasikan dengan sangat 

hati-hati. 

Berikut beberapa pedoman: 

Aplikasi yang mengakses layanan jaringan, filefile 

tertentu dan tidak melakukan aktivitas I/O 

yang lain, seharusnya dapat bekerja dengan benar 

didalam zona. 

Aplikasi yang memerlukan akses langsung ke 

perangkat tertentu, contohnya: sebuah partisi 

disk, dapat dilakukan jika zona tersebut 

dikonfigurasikan dengan benar. Namun demikian, 

dalam kasus-kasus tertentu hal ini meningkatkan 

resiko gangguan keamanan. 

Aplikasi yang memerlukan akses langsung perangkat 



73

Tinjauan 

tertentu seperti berikut ini mungkin perlu 

dimodifikasi untuk dapat berfungsi secara benar. 

Sebagai contoh, /dev/kmem, atau perangkat jaringan. 

Aplikasi seharusnya hanya menggunakan satu 

layanan IP dalam setiap zona. 



74

Tinjauan 

Zona dapat dikombinasikan dengan fasilitas 

manajemen sumber daya yang tersedia di OpenSolaris 

untuk menyediakan lingkungan komputasi yang lebih 

lengkap dan terisolasi. Berbeda dengan zona yang 

lebih berfungsi menyediakan keamanan, isolasi 

identitas dan isolasi kegagalan, fasilitas 

manajemen sumber daya digunakan untuk mencegah 

proses yang ada didalam sebuah zona menghabiskan 

terlalu banyak sumber daya atau untuk menjamin agar 

proses mendapatkan sumber daya sesuai dengan 

tingkat layanan yang diinginkannya. Zona dan 

manajement sumber daya keduanya sering disebut 

sebagai kontainer. 

Kunjungi http://opensolaris.org/os/community/zones/ 

faq untuk mendapatkan jawaban dari pertanyaanpertanyaan 

umum tentang zona dan alamat-alamat 

situs lain menyimpan dokumentasi terbarunya. 

Zona menyediakan lingkungan komputasi yang 

terlindungi bagi aplikasi-aplikasi Solaris. 

Sedangkan untuk lingkungan komputasi non-Solaris 

yang terlindungi dan terpisah tersedia melalui 

proyek OpenSolaris lain yang disebut BrandZ . 



75

Tinjauan 

Zona Bertanda-identitas (Branded 

Zones - BrandZ) 

BrandZ merupakan sebuah kerangka kerja yang 

memperluas infrastrukur zona yang ada sekarang 

untuk menciptakan Zona Bertanda-identitas, yang 

merupakan zona dengan lingkungan komputasi non- 

Solaris ada didalamnya. 

Zona Bertanda-identitas bisa berupa lingkungan 

komputasi sederhana dimana didalamnya perintahperintah 

standar Solaris digantikan oleh perintah 

GNU yang sama tanpa dimodifikasi, atau lingkungan 

yang kompleks berupa lingkungan pengguna Linux 

lengkap. 

BrandZ memperluas infrastruktur Zona di tingkat 

lingkungan pengguna dengan beberapa cara berikut 

ini: 

Sebuah tanda-identitas adalah sebuah atribut yang 

melekat pada sebuah zona, diberikan pada saat 

mengkonfigurasi zona. 

Setiap tanda-identitas menyediakan program dan 

prosedur instalasi sendiri, sehingga memiliki 

kemampuan untuk menginstal perangkat lunak apa 

pun didalam zona bertanda-identitas. 

Masing-masing tanda-identitas menyediakan skrip 

pra-boot dan pasca-boot untuk keperluan 

penyelesaian pengaturan atau konfigurasi pada 

saat boot. 

Perintah zonecfg dan zoneadm dapat digunakan untuk 

pengaturan dan memberikan informasi tipe tandaidentitas 

sebuah zona. 



76

Tinjauan 

BrandZ menyediakan beberapa titik inter-posisi 

dalam lingkungan kernel: 

Titik ini berada di jalur syscall, jalur pemuatan 

proses dan jalur penciptaan thread, dll. 

Titik inter-posisi hanya diterapkan terhadap 

proses-proses didalam zona Bertanda-identitas. 

Di titik ini, sebuah tanda-identitas dapat 

memilih untuk memodifikasi atau mengganti 

perilaku standar Solaris OS. 

Pada dasarnya setiap tanda-identitas yang berbeda 

memerlukan titik inter-posisi baru. 

Tanda-identitas “lx” memungkinkan aplikasi biner 

Linux dapat dijalankan tanpa dimodifikasi diatas 

Solairs, didalam zona yang menjalankan lingkungan 

penggunak Linux lengkap. Tanda-identitas lx 

memungkinakn perangkat lunak Linux di tingkatpengguna 

dapat berjalan dengan kernel OpenSolaris 

kernel, dan termasuk didalamnya adalah piranti yang 

diperluka untuk menginstal distribusi Linux CentOS 

atau RedHat Enterprise didalam zona diatas sistem 

Solaris. 

Tanda-identitas lx berjalan di sistem x86/x64 dan 

boot dengan kernel 32-bit atau 64-bit. Tetapi hanya 

aplikasi Linux 32-bit bisa berjalan. Hingga 

sekarang, fitur ini baru tersedia untuk arsitektur 

x86 dan AMDx64. Namun, memindahkannya ke sistem 

berarsitektur SPARC mungkin bisa menjadi proyek 

komunitas yang menarik karena BrandZ lx masih terus 

dikembangkan. 

Kunjungi 

http://opensolaris.org/os/community/brandz/installu 

ntuk mendapatkan informasi kebutuhan instalasi dan 

petunjunknya 

Proyek OpenSolaris memang ditujukan untuk mencari 

tantangan unik dalam pengembangan Sistem Operasi 

dan pengujian kinerja aplikasi yang menggunakan 



77

Tinjauan 

fitur tertentu misalnya zona. 



78

Tinjauan 

Jaringan Didalam Zona 

Berdasarkan cara yang dipilih untuk memberikan 

alamat IP pada sebuah zona Solaris maka zona 

terbagi sebagai berikut: 

Zona dengan IP-Eksklusif 

Zona dengan IP-Berbagi 

Zona dengan IP-Eksklusif memiliki lapisan 

fungsional IP mandiri, antarmuka jaringan fisik 

mandiri dan antarmuka VLAN mandiri. Konfigurasi 

jaringan zona dengan IP-Eksklusif identik dengan 

konfigurasi jaringan komputer fisik. 

Zona dengan IP-Berbagi berbagi lapisan fungsional 

IP dengan zona global, sehingga tertutup dari 

rincian konfigurasi perangkat jaringan, rute 

jaringan dan sebagainya. Masing-masing zona IPberbagi 

dapat diberikan alamat IPv4/IPv6. Meskipun 

berbagi lapisan fungsional IP, masing-masing zona 

IP-berbagi memiliki ketersediaan port yang mandiri. 

Aplikasi dapat mengikat diri ke INADDR_ANY dan hanya 

menerima lalulintas data yang ditujukan ke zona 

tersebut. 

Di dalam kedua tipe zona ini, pengamatan terhadap 

lalulintas data milik sebuah zona yang lain tidak 

dapat dilakukan. Paket yang berasal dari sebuah 

zona akan memiliki alamat IP pengirim yang dimiliki 

zona tersebut. Zona dengan IP-berbagi hanya dapat 

mengirim paket melalui antarmuka dengan alamat IP 

yang diberikan kepada zona tersebut. Zona dengan 

IP-berbagi hanya bisa menggunakan router default 

jika router tersebut dapat dijangkau secara 

langsung dari zona. Router default harus berada 

dalam sub-jaringan yang sama dengan zona-nya. 



79

Tinjauan 

Zona IP-berbagi tidak dapat mengubah konfigurasi 

jaringan atau tabel informasi rute dan tidak dapat 

mengakses konfigurasi jaringan milik zona yang 

lain. Perangkat logis /dev/ip tidak tersedia didalam 

zona IP-berbagi. Sebagai akibatnya agen SNMP harus 

mengakses /dev/arp bukan /dev/ip. Beberapa zona IPberbagi 

secara bersamaan dapat berbagi alamat IP 

broadcast dan bergabung di group multicast yang 

sama. 

Zona IP-berbagi juga memiliki keterbatasan 

kemampuan jaringan yang lain, seperti: 

Ketersediaan antarmuka jaringan fisik didalam 

zona tidak dimungkinkan 

IPFilter tidak dapat digunakan untuk menyaring 

paket diantara dua atau lebih zona 

Pemberian alamat IP untuk zona tidak bisa 

menggunakan DHCP 

Routing secara dinamis tidak dapat dilakukan 

Zona dengan IP-eksklusif tidak memiliki 

keterbatasan seperti diatas, dan dapat mengubah 

konfigurasi jaringan atau tabel informasi rute. 

Perangkat logis /dev/ip tersedia didalam zona dengan 

IP-eksklusif. 



80

Tinjauan 

Identitas Zona, Akses terhadap CPU 

dan Instalasi Paket 

Masing-masing zona mengontrol sendiri nama 

komputer, zona waktu dan layanan identitas seperti 

LDAP dan NIS. Program sysidtool yang dapat melakukan 

ini semua. Terpisahnya file /etc/passwd memungkinkan 

hak-hak khusus root didelegasikan ke masing-masing 

zona. Nomor ID pengguna yang sama dapat digunakan 

oleh nama pengguna yang berbeda ketika mereka ada 

di domain yang berbeda. 

Berdasarkan standar, semua zona bisa mengakses 

semua sumber daya CPU. Pembatasan akses terhadap 

sumber daya secara otomatis dilakukan ketika pool 

sumber daya dibuat. 

Didalam zona dapat diinstal paket hanya didalam 

zona yang bersangkutan. Patch juga dapat diinstall 

untuk paket tersebut. 

Patch Sistem diinstal didalam zona global. 

Kemudian, di dalam zona non-global secara otomatis 

dilakukan boot -s agar patchnya dapat berfungsi. 

Parameter paket SUNW_PKG_ALLZONES sebaiknya digunakan 

secara konsisten diantara zona global dan semua 

zona non-global. 

Parameter SUNW_PKG_HOLLOW menyebabkan nama paket 

muncul didalam zona non-global (NGZ) tetapi hanya 

untuk kelengkapan informasi ketergantungan paket 

karena sebenarnya paket tersebut tidak terinstal. 



81

Tinjauan 

Perangkat Didalam Zones 

Masing-masing zona memiliki akses ke perangkat 

masing-masing yang berbeda. Setiap zona memiliki 

akses terhadap sekumpulan bagian dari perangkat 

pseudo didalam direktori /dev. Aplikasi mengakses 

nama perangkat logis berdasarkan perangkatperangkat 

yang disajikan didalam direktori /dev. 

Direktori /dev tersedia didalam masing-masing zona 

non-global, tetapi direktori /devices tidak ada. 

Ketersediaan perangkat seperti random, console, and 

null dibolehkan jika tersedia didalam zona tetapi 

yang lainnya seperti /dev/kmem tidak dianjurkan dapat 

diakses dari zona non-global. 

Didalam zona izin akses terhadap perangkat dapat 

dimodifikasi tetapi perangkat baru tidak dapat 

dibuat, misalnya dengan fungsi mknod(2). 

Ketersediaan akses secara raw terhadap disk didalam 

zona harus dilakukan dengan hati-hati. Berbagi 

perangkat diantara beberapa zona juga bisa 

dilakukan tetapi tetap dengan mempertimbangan 

keamanan. 

Sebagai contoh, diasumsikan akses ke beberapa 

perangkat tertentu telah diberikan ke beberapa zona 

sekaligus. Dengan mengizinkan pengguna biasa 

mengakses secara block terhadap disk memungkinkan 

terjadinya panik sistem, ter-resetnya bus atau efek 

merugikan lainnya. 

Dengan penempatan sebuah perangkat fisik yang sama 

didalam beberapa zona, sebuah saluran koneksi 

tersembunyi dapat dibuat antara zona-zona yang 

bersangkutan. Aplikasi di zona global yang juga 

mengakses perangkat yang sama memiliki resiko 

datanya terubah atau rusak akibat serangan dari 

zona non-global. 



82

Tinjauan 

Prakiraan Penyembuhan-Diri 

(Predictive Self-Healing) 

Pra-kiraan Penyembuhan-Diri diimplementasi menjadi 

2 bagian di dalam Solaris 10 yaitu Arsitektur 

Manajemen Kegagalan dan Fasilitas Manajemen 

Layanan. 



83

Tinjauan 

Arsitektur Manajemen Kegagalan 

(Fault Management Architecture - 

FMA) 

Sistem Operasi Solaris menyediakan arsitektur baru, 

FMA, untuk menciptakan mekanisme penanganan 

kegagalan yang fleksibel, telemetri kegagalan, 

diagnosa perangkat lunak secara otomatis, agen yang 

akan bertindak jika terjadi kesalahan, dan model 

yang konsisten terhadap kegagalan sistem di setiap 

tingkat manajemen. 

Banyak komponen dari Solaris yang sudah terlibat 

kedalam FMA, termasuk diantaranya penangan 

kegagalan CPU dan Memori untuk UltraSPARC III dan 

IV; kartu antarmuka PCI untuk UltraSPARC dan 

Opteron. Berbagai proyek juga sedang berjalan, 

antara lain untuk dukungan penuh terhadap kegagalan 

CPU, Memori, and I/O di lingkungan komputasi 

Opteron, konversi penggerak perangkat utama dan 

integrasi dengan berbagai tingkat manajemen. 

Ketika sebuah subsistem dikonversikan agar bisa 

terlibat dalam Manajemen Kegagalan, mekanisme 

penanganan kegagalannya dibuat secara fleksibel 

sehingga sistem dapat dapat terus bekerja meskipun 

beberapa kegagalan ditingkat bawah terjadi, dan 

sebuah kejadian telemetri dibuat untuk memicu 

diagnosa dan tanggapan perbaikan secara otomatis. 

Piranti dan arsitektur Manajemen Kegagalan 

memungkinkan dikembangkannya mekanisme penyembuhandiri 

terhadap kegagalan perangkat lunak dan 

perangkat keras, baik untuk sumber daya yang 

berskala mikro atau makro, semuanya dengan sudut 

pandang yang seragam dan sederhana bagi 

administrator dan perangkat lunak manajemen sistem. 

Kunjungi http://opensolaris.org/os/community/fm 

untuk mendapatkan informasi agar bisa 



84

Tinjauan 

berpartisipasi dalam komunitas Manajemen Kegagalan 

atau mengunduh MIB unutk Manajemen Kegagalan yang 

hingga sekarang masih terus disempurnakan. 



85

Tinjauan 

Fasilitas Manajemen Layanan 

(Services Management Facility - 

SMF) 

SMF menciptakan sebuah model yang terintegrasi dan 

terus berkembang untuk kemudahan manajemen layananlayanan 

yang jumlahnya semakin besar di proyek 

OpenSolaris. Layanan-layanan tersebut antara lain: 

pengiriman surat elektronik, permintaan ftp dan 

eksekusi perintah secara remote. Kerangka kerja 

smf(5) menggantikan mekanisme startup init.d(4) yang 

ada sekarang dan termasuk juga perbaikan fitur 

inetd(1M). 

Bagi pengembang, SMF menyediakan keuntungan 

berikut: 

Secara otomatis me-restart layanan sesuai dengan 

urutan saling ketergantungannya. Banyak hal yang 

menyebabkan layanan berhenti antara lain: 

kegagalan administratif, kegagalan perangkat 

lunak atau kerusakah perangkat keras yang 

permanen. 

API yang sama untuk kebutuhan manajemen layanan, 

konfigurasi dan observasi 

Akses terhadap manajemen sumber daya yang 

berbasiskan layanan 

Men-debug proses boot menjadi lebih mudah 

Kunjungi 

http://opensolaris.org/os/community/smf/scfdot 

untuk melihat grafik layanan-layanan SMF dan 

ketergantungannya pada sebuah sistem x86 yang baru 

saja terinstal Sistem Operasi Solaris Nevada. 



86

Tinjauan 

Perunut Dinamis (Dynamic Tracing - 

DTrace) 

DTrace menyediakan sebuah infrastruktur kokoh yang 

dapat digunakan oleh administrator, pengembang dan 

teknisi operasional untuk secara cepat menjawab 

berbagai pertanyaan tentang perilaku Sistem Operasi 

dan program pengguna. 

DTrace memiliki kemampuan seperti berikut ini: 

Secara dinamis mengaktifkan dan mengatur ribuan 

probe 

Secara dinamis menghubungkan predikat dan aksi 

dengan probe 

Secara dinamis mengatur kapasitas penyangga saat 

merunut dan beban kerja probe Menguji data hasil 

merunut yang diperoleh dari sistem secara 

langsung atau dari file yang tersimpan setelah 

sistem mengalami kegagalan ditingkat kernel 

(system crash dump) 

Mengimplementasikan penyedia data tambahan untuk 

perunutan baru yang dipasangkan kedalam DTrace 

Mengimplementasi konsumen data hasil merunut yang 

akan menyajikan data 

Mengimplementasikan piranti untuk mengkonfigurasi 

probe DTrace 

Temukan situs komunitas DTrace di 

http://opensolaris.org/os/community/dtrace. 

Selain DTrace, proyek OpenSolaris juga menyediakan 

fasilitas pen-debug untuk pengembangan perangkat 

lunak di tingkat-bawah, misalnya pengembangan 

penggerak perangkat. 



87

Tinjauan 

Pen-debug Modular (Modular Debugger 

- MDB) 

MDB adalah sebuah pen-debug yang dirancang untuk 

menyediakan analisa masalah perangkat lunak yang 

memerlukan fasilitas pen-debug-an di tingkat-bawah, 

misalnya pengujian file core; dan pengetahuan 

tentang bahasa assembly diperlukan agar bisa 

melakukan diagnosa dan memperbaikinya. Umumnya, 

para pengembang kernel dan perangkat mengandalkan 

mdb untuk mencari jawaban mengapa dan dimana terjadi 

kesalahan pada kode pemograman mereka. 

MDB tersedia dalam dua perintah berbeda yaitu mdb 

dan kmdb, namun keduanya memiliki beberapa kesamaan 

fitur umum. Perintah mdb digunakan secara interaktif 

atau didalam skrip untuk mendebug proses di tingkat 

pengguna yang sedang berjalan, file core dari 

proses di tingkat pengguna, kernel crash dump, file 

object Sistem Operasi yang sedang berjalan dan file 

lainnya. Sedangkan kmdb digunakan untuk men-debug 

proses di tingkat kernel dan penggerak perangkat 

yang sedang berjalan, juga diperlukan untuk 

mengontrol dan menghentikan eksekusi intruksi 

didalam kernel. 

Terdapat komunitas yang aktif mendiskusikan MDB 

sebagai tempat untuk bertanya kepada para pakar 

atau melihat berbagai percakapan dan pertanyaan 

yang pernah disampaikan sebelumnya. Kunjungi 

http://opensolaris.org/os/community/mdb 



88

Tinjauan 

Sistem File ZFS 

Sistem file ZFS merupakan sistem file yang tidak 

dibatasi oleh perangkat keras tertentu, sehingga 

begitu mudah dan cepat untuk dibuat seperti membuat 

sebuah direktori, dan sistem file ini bertambah 

kapasitasnya secara otomatis sesuai dengan 

kapasitas maksimum yang dialokasikan didalam pool 

penyimpan datanya. 



89

Tinjauan 

Penggunaan Checksum dan Perbaikan 

Data 

Dengan ZFS, semua data dan metadata diproteksi dari 

kesalahan dengan checksum dimana algoritma yang 

akan digunakannya bisa dipilih. Semua perhitungan 

checksum dan perbaikan kesalahan data dilakukan di 

level sistem file dan semuanya transparan bagi 

aplikasi. Selain itu, ZFS juga berkemampuan 

memperbaiki-sendiri data dari kerusakan. ZFS 

mendukung pool penyimpan data berkemampuan 

redundansi data yaitu mirror dan sebuah variasi 

RAID-5. Ketika terdeteksi sebuah data blok rusak 

maka ZFS mengambil data yang masih utuh dari lokasi 

lain yang berisi data yang sama kemudian 

memperbaiki data blok yang rusak tersebut yaitu 

dengan menggantinya oleh data blok yang masih utuh. 

ZFS menyajikan model pool penyimpan data dimana 

model ini membuang konsep volume beserta 

masalahnya. Masalah-masalah tersebut meliputi: 

perlunya mempartisi, melakukan provision, kinerja 

yang tidak maksimal dan pemakaian kapasitas 

penyimpan yang tidak optimal 

Gabungan kapasitas I/O dari semua perangkat keras 

di dalam pool tersedia untuk untuk semua sistem 

file sepanjang waktu. 

Masing-masing pool penyimpan data terdiri dari satu 

atau lebih perangkat virtual yang menggambarkan 

disain penyimpan data fisiknya dan karakteristik 

kemampuan bertahan terhadap kerusakan. Kunjungi 

http://opensolaris.org/os/community/zfs/demos/basic 

s untuk menyaksikan demo administrasi sistem file 

ZFS yang berjudul “100 Mirrored Filesystems in 5 

Minutes”. 



90

Tinjauan 

RAID-Z 

Selain konfigurasi penyimpanan data tunggal dalam 

sebuah pool, ZFS juga menyediakan konfigurasi 

penyimpanan data redundansi ter-mirror dan 

redundansi RAID-Z yang memberikan perlindungan 

sangat baik terhadap kehilangan data. Konfigurasi 

RAID-Z merupakan perangkat penyimpan data virtual 

yang menyimpan data dan pariti secara tersebar di 

banyak disk sekaligus, mirip dengan RAID-5. 

Berbeda dengan RAID-5, RAID-Z menggunakan ukuran 

RAID stripe yang tidak tetap sehingga setiap 

operasi tulis selalu menjad operasi tulis fullstripe. 

Fitur ini hanya ada di ZFS karena ZFS 

mengintegrasikan manajemen sistem file dan 

perangkat keras. Pengintegrasian ini menyediakan 

suatu cara dimana metadata dari sistem file selalu 

memiliki cukup informasi tentang pondasi dari model 

replikasi datanya untuk menangani ukuran RAID 

stripe yang tidak tetap. RAID-Z merupakan solusi 

berbasis perangkat lunak pertama yang mengatasi 

kelemahan operasi tulis dari RAID-5. 



91

Tujuan 

6M O D U L 

Konsep Pemograman 

Modul ini menyajikan deskripsi umum tentang konsepkonsep 

dasar lingkungan pemograman OpenSolaris, 

yang meliputi: 

Manajemen Proses dan Sistem 

Pemograman Thread 

Fungsi-fungsi Dasar Kernel 

Penjadwalan CPU 

Men-debug Proses 

Sumber Bacaan 

Lain 

Solaris Internals (2nd Edition), PrenticeHall PTR 

(May 12, 2006) by Jim Mauro and RichardMcDougall 

Solaris Systems Programming, PrenticeHall PTR 

(August 19, 2004), by Rich Teer 

Multithreaded Programming Guide. SunMicrosystems, 

Inc., 2005. 

STREAMS Programming Guide. SunMicrosystems, Inc., 

2005. 

Solaris 64-bit Developer’s Guide. 

SunMicrosystems, Inc., 2005. 



92



Unit dasar beban kerja sistem komputasi adalah 

proses. Setiap proses diberi tanda pengenal berupa 

nomor identifikasi proses (PID), nomor ini dibuat 

secara berurutan didalam sistem. Sesuai standarnya, 

setiap setiap pengguna akan diberikan sebuah proyek 

oleh sistem administrator, proyek merupakan sebuah 

identitas administratif yang bersifat global. 

Setiap login ke sebuah proyek akan menciptakan 

sebuah tugas (task), tugas merupakan mekanisme 

pengelompokan proses. Sebuah tugas terdiri dari 

proses login dan anak proses lain yang 

mengikutinya. 

Fasilitas pool sumber-daya menggabungkan beberapa 

sumber-daya yang tersedia bagi proses kedalam 

sebuah abstraksi umum disebut pool. Himpunan 

prosesor dan sumber-daya lain dikonfigurasikan, 

dikelompokan dan diberi label sedemikian rupa 

sehingga menjadi komponen beban-kerja yang terkait 

sebagai himpunan bagian dari total sumber-daya yang 

dimiliki sistem. 

Jika fasilitas pool tidak aktif maka semua proses 

akan dimiliki oleh pool yang sama yaitu 

pool_default, dan himpunan prosesor diatur melalui 

panggilan fungsi sistem pset(). Ketika fasilitas 

pool diaktifkan, himpunan proses harus diatur 

dengan menggunakan fasilitas pool. Sebuah pool baru 

diciptakan dan dilekatkan dengan himpunan prosesor 

tertentu. Berikutnya, proses dilekatkan dengan pool 

yang memiliki himpunan sumber-daya tertentu. 

Dengan menggunakan OpenGrok untuk melihat sumber 

kode pemograman pool.c, dapt dilihat komentar yang 

menjelaskan hubungan antara tugas, pool, proyek dan 

proses, seperti berikut ini: 

“Tindakan untuk melekatkan tugas dan proyek dengan 



93


pool bersifat atomik. Artinya, baik itu semua 

proses yang ada didalam sebuah tugas atau proyek 

akan dilekatkan ke sebuah pool baru, atau tetap 

melekat di pool sebelumnya (jika terjadi 

kegagalan). Proses yang ada didalam sebuah tugas 

atau proyek hanya bisa dilekatkan ke pool yang 

berbeda jika proses-proses tersebut masing-masing 

dilekatkan-ulang satu-persatu sebagai proses 

tunggal. 



94


Threads atau LWPs dari proses yang sama bukan 

merupakan obyek yang dilekatkan pada sebuah pool, 

dan keduanya dilekatkan dengan himpunan sumber-daya 

yang sama yang terkait dengan pool sumber-daya dari 

proses yang bersangkutan. 

Proses dapat juga dijalankan didalam zona. Zona 

diciptakan oleh adminstrator sistem, biasanya untuk 

alasan keamanan, agar dapat mengisolasi sekelompok 

pengguna atau proses dari yang lainnya.” 



95


Pemograman Thread 

Sejauh ini telah dipelajari proses dalam konteksnya 

dengan tugas, proyek, pool sumber daya, zona dan 

zona bertanda-identitas, berikutnya akan dipelajari 

proses dalam konteksnya dengan thread. 

UNIX sejak dulu sudah mendukung konsep thread. 

Masing-masing proses memiliki setidaknya satu 

thread, sehingga pemograman dengan banyak proses 

berarti pemograman dengan banyak thread. Tetapi, 

proses juga memerlukan area alamat memori, sehingga 

penciptaan sebuah proses berarti juga melibatkan 

penciptaan sebuah area alamat memori baru. 

Komunikasi antar thread dalam satu proses merupakan 

komunikasi yang sederhana karena semua thread 

berbagi banyak hal, termasuk area alamat memori dan 

deskriptor file terbuka yang sama. Sehingga data 

yang dihasilkan oleh satu thread dengan segera 

tersedia untuk diakses oleh thread yang lain. 

File librari yang tersedia untuk permograman 

banyak-thread (Multithreading) yaitu libpthread untuk 

thread POSIX dan libthread untuk thread OpenSolaris. 

Pemograman banyak-thread menyediakan fleksibilitas 

dengan memisahkan sumber daya di tingkat-kernel 

dengan sumber daya di tingkat-pengguna. Di 

OpenSolaris, pemograman banyak-thread mendukung 

himpunan antarmuka yang disediakan oleh librari C 

standar. 

Gunakan fungsi pthread_create(3C) untuk menambahkan 

thread pengontrol baru kedalam sebuah proses. 

int pthread_create(pthread_t *tid, const pthread_attr_t *tattr, 

void*(*start_routine)(void *), void *arg); 

Fungsi pthread_create() dipanggil dengan attr yang 

telah memiliki kondisi status yang diperlukan. 

Fungsi start_routine merupakan fungsi yang berfungsi 



96


untuk memacu sebuah thread baru untuk memulai 

eksekusi. Ketika fungsi start_routine selesai 

dipanggil, thread tersebut keluar dengan status 

keluaran yang ditentukan oleh nilai-balik yang 

dikembalikan oleh fungsi start_routine. 



97


Fungsi pthread_create() menghasilkan nilai-balik nol 

jika panggilan fungsi tersebut berhasil 

diselesaikan tanpa kesalahan. Nilai-balik selain 

nol menandakan adanya kesalahan. Lihat informasi 

yang tersedia di /on/usr/src/lib/libc/spec/threads.spec 

dengan OpenGrok untuk mendapat daftar lengkap 

fungsi-fungsi pthread dan cara deklarasinya. 

Sinkronisasi thread diperlukan untuk mengontrol 

aliran program dan akses ke data yang digunakan 

secara bersamaan oleh beberapa thread yang sedang 

dieksekusi. Ada empat metode sinkronisasi obyek 

yaitu penguncian mutex, penguncian baca/tulis, 

variabel kondisi, and penghitungan tanda bendera. 

Penguncian mutex (Mutex locks) mengizinkan hanya 

satu thread pada saat tertentu mengeksekusi area 

kode tertentu atau mengakses data tertentu. 

Penguncian baca/tulis (Read/write locks) 

mengizinkan pembacaan data secara bersamaan 

tetapi penulisan data diberikan secara eksklusif 

terhadap sumber daya terproteksi yang digunakan 

secara bersama. Agar dapat melakukan penulisan 

data, sebuah thread harus mendapatkan dulu 

pengunci penulisan eksklusif. Pengunci penulisan 

eksklusif tidak akan diberikan lagi sampai semua 

kunci pembacaan telah dilepaskan oleh thread yang 

lain. 

Variabel kondisi (Condition variables) memblokir 

thread hingga kondisi tertentu memiliki nila 

benar. 

Penghintungan tanda bendera (Counting semaphores) 

biasanya digunakan untuk mengkoordinasikan akses 

sebuah sumber daya. Penghitungan tanda bendera 

akan menentukan batas berapa banyak thread dapat 

memiliki akses ke sebuah tanda bendera. Ketika 

limit penghitungan tercapai; thread lain yang 

mencoba mengakses sumber daya akan diblokir. 



98


Sinkronisasi 

Obyek sinkronisasi merupakan variabel didalam 

memori yang dapat diakses datanya. Thread yang 

berasal dari proses yang berbeda dapat saling 

berkomu-nikasi melalui obyek sinkronisasi yang 

tersimpan didalam memori-bersama yang terkontrol 

oleh masing-masing thread. 

Thread dapat saling berkomunikasi meskipun 

sebenarnya thread yang berasal dari proses yang 

berbeda secara umum tidak saling terlihat. Obyek 

sinkroniasi juga dapat disimpan dalam file. Obyek 

sinkronisasi dapat memiliki waktu hidup yang lebih 

lama daripada waktu hidup penciptaan proses. 

Gunakan OpenGrok untuk menemukan kode pemograman 

libthread dan informasi penting lain didalam 

mutex.c, perhatikan juga informasi berikut yang 

diambil dari sebagian komentar sebuah kode 

pemogramman: 

Implementation of all threads interfaces between ld.so.1 and 

libthread. In a non-threaded environment all thread interfaces 

are vectored to noops. When called via _ld_concurrency() from 

libthread these vectors are reassigned to real threads 

interfaces. 

Two models are supported: 

TI_VERSION == 1 Under this model libthread provides 

rw_rwlock/rw_unlock, through which we vector all 

rt_mutex_lock/rt_mutex_unlock calls. Under lib/libthread these 

interfaces provided _sigon/_sigoff (unlike lwp/libthread that 

provided signal blocking via bind_guard/bind_clear. 

TI_VERSION == 2 Under this model only libthreads 

bind_guard/bind_clear and thr_self interfaces are used. Both 

libthreads block signals under the bind_guard/bind_clear 

interfaces. Lower level locking is derived from internally bound 

_lwp_ interfaces. This removes recursive problems encountered 

when obtaining locking interfaces from libthread. The use of 

mutexes over reader/writer locks also enables the use of 



99


condition variables for controlling thread concurrency (allows 

access to objects only after their .init has completed). 

Setelah memahami bagaimana obyek sinkronisasi 

didefinisikan dalam pemograman banyak-thread, 

berikutnya dijelaskan bagaimana obyek-obyek ini 

diatur dengan kelas-kelas penjadwalan. 



100


Penjadwalan CPU 

Proses dieksekusi didalam sebuah kelas penjadwalan 

tertentu yang masing-masing memiliki kebijakan 

penjadwalan yang berbeda, seperit dijelaskan 

berikut ini: 

Realtime (RT) – Kelas penjadwalan dengan 

prioritas tertinggi yang menyediakan kebijakan 

penjadwalan untuk proses yang memerlukan 

tanggapan cepat dan pengontrolan prioritas 

penjadwalan secara mutlak oleh pengguna atau 

aplikasi. Penjadwalan RT dapat diberikan kepada 

seluruh proses atau kepada satu atau lebih 

lightweight processes (LWPs) dari sebuah proses. 

Diperlukan hak istimewa proc_priocntl untuk dapat 

menggunakan kelas Realtime. Informasi lebih 

lanjut dapat diperoleh di manual privileges (5). 

System (SYS) – Kelas penjadwlan dengan prioritas 

menengah, kelas ini tidak dapat diberikan kepada 

proses pengguna. 

Timeshare (TS) – Kelas penjadwalan dengan 

prioritas terendah dan menjadi kelas standar 

untuk proses pengguna. Kebijakan TS adalah 

mendistribusikan sumber daya CPU secara merata 

diantara proses-proses dengan karakteristik 

konsumsi CPU yang berbeda. Proses-proses lain 

milik Kernel dapat memonopoli prosesor dalam 

jangka waktu yang singkat tanpa menyebabkan 

penurunan waktu-tanggap yang dirasakan oleh 

pengguna. 

Inter-Active (IA) – Kebijakan IA adalah selain 


diantara proses-proses dengan karakteristik 

konsumsi CPU yang berbeda tetapi juga menyediakan 

waktu-tanggap yang baik untuk berinteraksi dengan 

pengguna. 

Fair Share (FSS) – Kebijakan FSS adalah 



101



diantara beberapa proyek, tidak tergantung jumlah 

proses yang dimiliki proyek bersangkutan. Setiap 

proyek mendapatkan besar presentase tertentu 

untuk mengontrol hak pemanfaatan sumber daya CPU. 

Besarnya pemanfaatan sumber daya CPU selalu 

dicatat setiap waktu, sehingga jatah hak 

pemanfaatannya semakin dikurangi untuk proyek 

yang dengan pemakaian CPU besar dan akan 

ditambahkankan untuk proyek dengan pemakaian CPU 

kecil. 



102


Fixed-Priority (FX) – Kebijakan FX menyediakan 

penjadwalan preemptive dengan prioritas tetap 

bagi proses yang memerlukan prioritas penjadwalan 

yang tidak secara dinamis disesuaikan oleh sistem 

dan pengguna atau aplikasi yang bisa mengontrol 

sendiri prioritas penjadwalannya. Kelas ini dapat 

digunakan untuk memulai pengubahan kebijakan 

pengalokasian CPU. 

Kelas penjadwalan diberikan kepada masing-masing 

LWP. Setiap thread mendapatkan kelas penjadwalan 

dan prioritas dari LWP dimana thread tersebut 

berasal. Masing-masing LWP dalam sebuah proses 

dapat memiliki kelas penjadwalan dan prioritas unik 

yang diperlakukan berbeda oleh kernel. Prioritas 

thread akan menentukan persaingan untuk mendapatkan 

obyek sinkronisasi. 

Kelas penjadwalan RT dan TS keduanya memanggil 

fungsi priocntl(2) untuk menentukan tingkat prioritas 

sebuah proses atau LWP dalam sebuah proses. Gunakan 

OpenGrok mencari dasar kode pemograman fungsi 

priocntl, dari file rtsched.c dapat diketahui variabelvariabel 

yang digunakan oleh kelas penjadwalan RT 

and TS sebagai berikut: 

27 #pragma ident "@(#)rtsched.c 1.10 05/06/08 SMI" 

28 

29 #include "lint.h" 

30 #include "thr_uberdata.h" 

31 #include 

32 #include 

33 #include 

34 #include 

35 #include 

36 #include 

37 

38 /* 

39 * The following variables are used for caching information 

40 * for priocntl TS and RT scheduling classs. 

41 */ 

42 struct pcclass ts_class, rt_class; 

43 



103


44 static rtdpent_t *rt_dptbl; /* RT class parameter table */ 

45 static int rt_rrmin; 

46 static int rt_rrmax; 

47 static int rt_fifomin; 

48 static int rt_fifomax; 

49 static int rt_othermin; 

50 static int rt_othermax; 

Dengan mengetikan perintah man priocntl di sebuah 

jendela terminal, diperlihatkan rincian informasi 

yang berhubungan dengan masing-masing kelas 

penjadwalan, atribut, dan pemakaiannya. 

% man priocntl 

Reformatting page. Please Wait... done 

User Commands priocntl(1) 

NAME 

priocntl - display or set scheduling parameters of specified 

process(es) 

SYNOPSIS 

priocntl -l 

priocntl -d [-i idtype] [idlist] 

priocntl -s [-c class] [ class-specific options] [-i 

idtype] [idlist] 

priocntl -e [-c class] [ class-specific options] command 

[argument(s)] 

DESCRIPTION 

The priocntl command displays or sets scheduling parameters of 

the specified process(es). It can also be used to display the 

current configuration information for the system’s process 

scheduler or execute a command with specified scheduling 

parameters. 

Processes fall into distinct classes with a separate scheduling 

policy applied to each class. The process classes currently 

supported are the real-time class, time-sharing class, 

interactive class, fair-share class, and the fixed priority 

class. The characteristics of these classes and the classspecific 

options they accept are described below in the USAGE 

section under the headings Real-Time Class, Time- Sharing 

Class, Inter-Active Class, Fair-Share Class, and 

--More--(4%) 



104


Tinjauan Umum Kernel 

Setelah memiliki pemahaman di tingkat-atas tentang 

proses, thread dan penjadwalan, berikutnya akan 

disajikan penjelasan tentang kernel dan bagaimana 

modul kernel berbeda dengan program pengguna. 

Kernel Solaris berperan melakukan hal-hal berikut: 

Manajemen sumber daya sistem, termasuk 

diantaranya sistem file, proses dan perangkat 

keras. 

Menyediakan layanan sistem kepada aplikasi 

seperti manajemen I/O, memori virtual dan 

penjadwalan. 

Mengkoordinasikan interaksi antara proses 

pengguna dan sumber daya sistem. 

Memberikan prioritas, melayani permintaan atas 

sumber daya, melayani interupsi perangkat keras 

dan eksepsi. 

Menjadwalkan dan mengganti thread, area memori 

dan men-swap proses. 

Pada bagian berikut ini dijelaskan beberapa 

perbedaan penting antara modul kernel dan program 

pengguna. 



105


Perbedaan Antara Eksekusi Modul 

Kernel dan Program Pengguna 

Berikut adalah karakteristik-karakteristik modul 

kernel yang membedakannya dengan program pengguna 

pada saat dieksekusi: 

Modul kernel memiliki area alamat memori yang 

terpisah. Sebuah modul berjalan di area kernel. 

Aplikasi berjalan di area pengguna. Perangkat 

lunak sistem diproteksi dari program pengguna. 

Area kernel dan area pengguna masing-masing 

memiliki area alamat memori sendiri. 

Modul kernel memiliki hak eksekusi lebih tinggi. 

Kode pemograman yang berjalan di area kernel 

memiliki lebih banyak hak istimewa daripada kode 

pemograman yang berjalan di area kernel. 

Modul kernel tidak dieksekusi secara berurutan. 

Program pengguna biasanya dieksekusi secara 

berurutan dan melakukan satu tugas tunggal sejak 

awal hingga berhenti. Modul kernel tidak 

dieksekusi secara berurutan. Modul kernel 

mendaftarkan diri sebagai komponen kernel agar 

bisa melayani permintaan layanan yang akan 

datang. 

Modul kernel dapat diinterupsi. Bebarapa proses 

dapat secara bersamaan mengirimkan permintaan 

kepada sebuah modul kernel. Contohnya, sebuah 

program kernel bertugas menangani interupsi bisa 

saja mengirimkan permintaan kepada sebuah modul 

kernel yang sedang melayani panggilan sistem pada 

saat yang sama. Didalam sistem berprosesor-banyak 

simetrik (Symmetric Multiprocessor, SMP), sebuah 

modul kernel dapat dieksekusi secara bersamaan 

oleh beberapa CPU. 



106


Modul kernel harus bersifat preemptive. Meskipun 

sebuah program penggerak tidak dapat memblokir 

sebuah modul kernel, ini tidak berarti kernel 

modul ini aman. Rancanglah sebuah program 

penggerak dengan asumsi bahwa kernel modul yang 

bersangkutan bersifat preemptive. 

Modul kernel dapat berbagi data. Thread yang 

berbeda dari sebuah program aplikasi tidak perlu 

untuk berbagi data. Berlawanan dengan struktur 

data dan kode pemograman rutin sebagai komponen 

program penggerak yang digunakan secara bersamaan 

oleh semua thread yang ada dalam program 

penggereak tersebut. Sebuah program penggerak 

harus dapat menangani masalah perebutan sumber 

daya sebagai akibat permintaan yang banyak. 

Rancanglah struktur data program penggerak dengan 

penuh pertimbangan untuk menjaga agar beberapa 

thread tetap dieksekusi secara terpisah. 



107


Perbedaan Struktural antara Modul 

Kernel Modules dan Program Pengguna 

Berikut adalah karakteristik-karakteristik struktur 

modul kernel yang membedakannya dengan struktur 

program pengguna: 

Modul kernel tidak mendefinisikan program utama. 

Modul kernel, termasuk program penggerak 

perangkat tidak memiliki fungsi rutin utama 

main(). Sebaliknya, modul kernel merupakan 

kumpulan fungsi sub-rutin dan data. 

Modul kernel hanya di-link ke komponen librari 

kernel. Modul kernel tidak di-link ke librari 

yang digunakan oleh program pengguna. Kernel 

module hanya bisa memanggil fungsi-fungsi yang 

telah dieksport oleh kernel. 

Modul kernel menggunakan file header yang 

berbeda. Modul kernel memerlukan himpunan file 

header yang berbeda dengan file header yang 

diperlukan oleh program pengguna. Daftar file 

header yang diperlukan dapat dilihat di halaman 

manual masing-masing fungsi. Modul kernel bisa 

saja mengikutkan file header yang digunakan 

bersama oleh program pengguna jika antarmuka 

antara kode di area user dan area kernel didalam 

header file tersebut didefinisikan secara 

kondisional dengan makro _KERNEL. 

Modul kernel sebaiknya menghindari pemakaian 

variabel global. Penghindaran variabel global 

didalam kernel modul jauh lebih penting 

dibandingkan penghindaran variabel global didalam 

program pengguna. Sebisa mungkin, deklarasikan 

simbol sebagai statik. Ketika penggunaan simbol 

global tidak dapat dihindari, tambahkan prefix ke 

nama simbol global tersebut agar unik didalam 

kernel. Penggunan prefix untuk simbol private 

dalam modul juga merupakan kebiasaan yang baik. 



108


Modul kernel dapat dibuat berdasarkan kebutuhan 

spesifik perangkat keras. Modul kernel dapat 

menggunakn register proses secara khusus hanya 

untuk melakukan fungsi yang specifik. Modul 

kernel dapat dioptimalisasikan untuk jenis 

prosesor tertentu. Librari juga dapat dibuat 

berdasarkan kebutuhan spesifik tertentu, seperti 

di OpenSolaris memiliki librari untuk sistem x86/ 

x64 and UltraSPARC. Jadi, jika kernel dapat 

menggunakan register untuk fungsi tertentu maka 

kode pemograman dapat dibuat sesuai kebutuhan 

kernel dan pengguna/librari. 

Modul kernel dapat dimuatkan dan dibongkarmuatkan 

sesuai permintaan. Kumpulan fungsi sub-rutin dan 

data yang merupakan bagian program penggerak 

perangkat dapat dikompilasi menjadi sebuah kode 

obyek dari sebuah module tunggal yang dapat 

dimuatkan. Modul ini berikutnya dapat secara 

dinamis atau statik di-link kedalam kernel dan 

di-unlink dari kernel. Penambahan fungsi baru 

kedalam kernel dapat dilakukan pada saat kernel 

aktif dan berjalan. Pengujian versi terbaru 

sebuah program penggerak dapat dilakukan tanpa 

me-reboot sistem. 



109


Men-debug Proses 

Men-debug proses pada semua tingkat dari tahap 

pengembangannya merupakan bagian kunci dari 

pembuatan modul kernel. 

Pencarian kode pemograman libthread dengan 

OpenGrok, mengarahkan kita ke file mdb_tdb.c yang 

menjelaskan hubungan antara multi-threaded 

debugging dan bagaimana mdb bekerja: 

In order to properly debug multi-threaded programs, the proc 

target must be able to query and modify information such as a 

thread’s register set using either the native LWP services 

provided by libproc (if the process is not linked with 

libthread), or using the services provided by libthread_db (if 

the process is linked with libthread). 

Additionally, a process may begin life as a single-threaded 

process and then later dlopen() libthread, so we must be 

prepared to switch modes on-the-fly. There are also two possible 

libthread implementations (one in /usr/lib and one in 

/usr/lib/lwp) so we cannot link mdb against libthread_db 

directly; instead, we must dlopen the appropriate libthread_db 

on-the-fly based on which libthread.so the victim process has 

open. Finally, mdb is designed so that multiple targets can be 

active simultaneously, so we could even have *both* 

libthread_db’s open at the same time. 

This might happen if you were looking at two multi-threaded user 

processes inside of a crash dump, one using 

/usr/lib/libthread.so and the other using 

/usr/lib/lwp/libthread.so. To meet these requirements, we 

implement a libthread_db "cache" in this file. The proc target 

calls mdb_tdb_load() with the pathname of a libthread_db to 

load, and if it is not already open, we dlopen() it, look up the 

symbols we need to reference, and fill in an ops vector which we 

return to the caller. 

Once an object is loaded, we don’t bother unloading it unless 

the entire cache is explicitly flushed. This mechanism also has 

the nice property that we don’t bother loading libthread_db 

until we need it, so the debugger starts up faster. 



110


Perintah-perintah mdb berikut dapat digunakan untuk 

mengakses LWP dari sebuah progarm dengan banyakthread: 

$l Menampilkan LWP ID dari thread representatif 

jika targetnya adalah proses pengguna. 

$L Menampilan LWP ID dari masin-masing LWP 

didalam target jika targetnya adalah proses 

pengguna. 

pid::attach Melekatkan ke sebuah proses dengan 

menggunakan ID prosesnya, pid 

::release Melepaskan proses atau file core yang 

sebelumnya dilekatkan. Proses masih dapat 

melanjutkan eksekusinya dengan menggunakan prun(1) 

atau MDB atau pen-debug yang lain. 

address::context Melakukan context switch terhadap 

proses yang ditentukan. Perintah ini menetapkan 

conditional breakpoints yang seringkali berguna. 

[ addr ] ::bp [+/-dDestT] [-c cmd] [-n count] sym ... 

Menentukan breakpoint pada lokasi tertentu. 

addr ::delete [id | all] Menghapus event specifiers 

dengan nomor ID tertentu 

Probe DTrace juga dikonstruksikan dengan cara yang 

sama seperti MDB. Pada halaman berikutnya terdapat 

latihan lab menggunakan DTrace kemudian MDB ketika 

men-debug semakin sulit dan kompleks. 



111

Tujuan 

7M O D U L 

Memulai Penggunaan DTrace 

Tujuan dari latihan lab ini adalah untuk 

memperkenalkan DTrace dengan menggunakan skrip 

probe untuk sebuah system call dengan DTrace. 

Sumber Bacaan 

Lain 

Solaris Dynamic Tracing Guide. SunMicrosystems, 

Inc., 2007. 

DTrace User Guide, SunMicrosystems, Inc., 2006 



112

Mengaktifkan Probe DTrace Sederhana 


Setelah menyelesaikan latihan-latihan di modul ini 

diharapkan peserta memiliki pemahaman dasar tentang 

probe-probe didalam DTrace. 

Ringkasan 

Pembelajaran DTrace dimulai dengan membuat 

permintaan yang sangat sederhana yaitu menggunakan 

probe yang bernama BEGIN; probe ini akan terpicu 

(aktif) satu kali setiap ada permintaan merunut 

baru. Kita dapat menggunakan opsi –n dari perintah 

dtrace(1M) untuk mengaktifkan sebuah probe dengan 

menggunakan nama string-nya. 



113


Mengaktifkan Probe DTrace 

Sederhana 

1.Buka jendela terminal 

2.Mengaktifkan sebuah probe: 

# dtrace -n BEGIN 

Setelah jeda beberapa saat, dapat disaksikan 

dtrace menyatakan bahwa sebuah probe diaktifkan 

dan sebaris informasi keluaran muncul 

mengindikasi probe BEGIN sudah dipicu. 

Setelah muncul keluaran ini, dtrace tetap menunggu 

probe yang lain untuk memicu. Karena kita tidak 

akan mengaktifkan probe yang lain dan probe BEGIN 

cukup hanya diaktifkan satu kali, tekan Control-C 

untuk keluar dari dtrace dan kembali ke prompt 

shell: 

3.Kembali ke shell prompt dengan menekan Control-C: 

# dtrace -n BEGIN 

dtrace: description ’BEGIN’ matched 1 probe 

CPU ID FUNCTION:NAME 

0 1 :BEGIN 

^C 

# 

Keluaran ini menjelaskan bahwa probe bernama 

BEGIN dipicu satu kali dan baik nama dan nomor 

ID, 1 ditampilkan. Perhatikan bahwa berdasarkan 

standar, nomor CPU dimana probe dipicu yang akan 

ditampilkan. Dalam contoh ini, kolom CPU 

mengindikasinya bahwa perintah dtrace dieksekusi 

pada CPU 0 ketika probenya dipicu. 

Permintaan DTrace dapat dikonstruksi dengan 

menggunakan berapapun jumlah probe dan aksi. 

Berikutnya, buat lagi sebuah permintaan sederhana 

menggunakan dua probe yaitu dengan penambahan 

probe END pada contoh perintah sebelumnya. Probe 

END memicu satu kali ketika merunut telah 

lengkap. 



114


4.Tambahkan probe END: 

# dtrace -n BEGIN -n END 

dtrace: description ’BEGIN’ matched 1 probe 

dtrace: description ’END’ matched 1 probe 


0 1 :BEGIN 

^C 

0 2 :END 

# 

Probe END memicu satu kali ketika merunut telah 

lengkap. Seperti diperlihatkan, dengan menekan 

Control-C untuk keluar DTrace akan membangkitkan 

probe END. DTrace menampilkan informasi bahwa 

probe ini memicu sebelum keluar. 



115

Menampilkan Traceable Probes 

Menampilkan Probe Perunut 

Tujuan dari lab ini adalah untuk mengenal probe 

lebih jauh dan memperlihatkan bagaimana menampilkan 

probe yang ada dalam sebuah sistem. 

Ringkasan 

Pada contoh-contoh sebelumnya, telah dipelajari 2 

probe sederhana bernama BEGIN dan END. Tetapi 

darimana kedua probe ini sebenarnya berasal? Probe 

DTrace berasal dari himpunan modul-modul kernel 

yang disebut penyedia (provider), dimana masingmasing 

penyedia melakukan suatu bentuk 

instrumentasi tertentu untuk membuat probe. Sebagai 

contoh, penyedia syscall menyediakan probe untuk 

setiap panggilan system( system call) and the 

penyedia fbt menyediakan probe untuk setiap fungsi 

yang ada didalam kernel. 

Ketika menggunakan DTrace, setiap penyedia 

diberikan kesempatan untuk mempublikasikan setiap 

probe yang ada yang di kerangka kerja DTrace. 

Berikutnya setiap probe yang telah dipublikasikan 

dapat diaktifkan dan dilekatkan aksi perunut. 



116


Menampilkan Probe Perunut 


2.Ketikan perintah berikut.: 

# dtrace 

Opsi-opsi yang ada perintah dtrace ditampilkan. 

3.Ketikan perintah dtrace dengan opsi –l : 

# dtrace -l | more 

ID PROVIDER MODULE FUNCTION NAME 

1 dtrace BEGIN 

2 dtrace END 

3 dtrace ERROR 

4 lockstat genunix mutex_enter adaptiveacquire 

5 lockstat genunix mutex_enter adaptiveblock 

6 lockstat genunix mutex_enter adaptive-spin 

7 lockstat genunix mutex_exit adaptiverelease 

--More-- 

Probe-probe yang tersedia di sistem ditampilkan 

dalam lima kolom informasi sebagai berikut: 

ID – Nomor urut identifikasi internal dari 

probe yang ditampilkan 

Provider – Nama Penyedia. Penyedia digunakan 

untuk mengklasifikasikan probe. Ini juga 

digunakan sebagai metode instrumentasinya. 

Module – Nama modul Unix atau librari aplikasi 

dari probe yang bersangkutan 

Function – Nama fungsi dimana sebuah probe 

berasal. 

Name – Nama probe 



117


4.Gunakan simbol pipa untuk meneruskan keluaran 

dari perintah sebelumnya kedalam perintah wc 

untuk menghitung jumlah total probe yang ada di 

sistem: 

# dtrace -l | wc -l 

30122 

Jumlah probe yang diketahui oleh sistem 

ditampilkan sebagai keluarannya. Jumlah ini bisa 

berbeda tergantung tipe sistemnya. 

5.Tambahkan opsi-opsi berikut untum mem-filter 

tampilannya: 

-P untuk penyedia 

-m for modul 

-f untuk fungsi 

-n untuk name 

Perhatikan contoh-contoh berikut: 

# dtrace -l -P lockstat 


4 lockstat genunix mutex_enter adaptive-acquire 

5 lockstat genunix mutex_enter adaptive-block 

6 lockstat genunix mutex_enter adaptive-spin 

7 lockstat genunix mutex_exit adaptive-release 

Hanya probe-probe yang ada didalam penyedia 

lockstat yang ditampilkan 

# dtrace -l -m ufs 


15 sysinfo ufs ufs_idle_free ufsinopage 

16 sysinfo ufs ufs_iget_internal ufsiget 

356 fbt ufs allocg entry 

Hanya probe-probe yang ada di modul UFS yang 

ditampikan. 



118


# dtrace -l -f open 


4 syscall open entry 

5 syscall open return 

116 fbt genunix open entry 

117 fbt genunix open return 

Hanya probe-probe dengan name fungsi open yang 

ditampilkan. 

# dtrace -l -n start 


506 proc unix lwp_rtt_initial start 

2766 io genunix default_physio start 

2768 io genunix aphysio start 

5909 io nfs nfs4_bio start 

Perintah diatas menampilkan semua probe yang 

memiliki nama probe start. 



119

Pemograman Bahasa D 


Setelah memiliki sedikit pemahaman tentang 

penamaan, mengaktifkan dan menampilkan probe, 

langkah berikutnya diharapkan peserta bisa 

menuliskan sebuah versi program DTrace sederhana, 

"Hello, World." 

Ringkasan 

Lab ini mendemonstrasikan bahwa DTrce dapat 

dituliskan dalam sebuah teks file dengan mengunakan 

bahasa pemograman D, selain mengkonstruksinya 

dengan perintah baris. 



120


Menuliskan Program DTrace 


2.Gunakat editor teks, buat sebuah file baru 

bernama hello.d. 

3.Ketikan sebuah program D: 

BEGIN 

{ 

trace("hello, world"); 

exit(0); 

} 

4.Simpan file the hello.d. 

5.Jalankan program tersebut menggunakan opsi dtrace – 

s: 

# dtrace -s hello.d 

dtrace: script ’hello.d’ matched 1 probe 


0 1 :BEGIN hello, world 

# 

Seperti diperlihat diatas, dtrace menampilkan 

keluaran yang sama seperti sebelumnya kemudian 

diikuti teks “hello, world”. Tidak seperti contoh 

sebelumnya, tidak diperlukan waktu untuk menunggu 

ataupun menekan Control-C. 

Perubahan ini merupakan efek dari aksi yang 

dimiliki oleh probe BEGIN didalam hello.d. Di 

halaman berikut, akan digali lebih dalam struktur 

program D untuk memahami apa yang sebenarnya 

terjadi. 



121


Diskusi 

Setiap program D terdiri atas sebuah urutan klausaklausa, 

masing-masing klausa menggambarkan satu 

atau lebih probe yang akan diaktifkan, dan 

sekumpulan aksi opsional yang akan dilakukan ketika 

probe terpicu. Aksi sendiri ditampilkan sebagai 

kumpulan urutan pernyataan yang diapit tanda kurung 

{ } setelah nama probe. Setiap pernyataan diakhiri 

oleh sebuah tanda titik-koma (;). 

Pernyataan pertama menggunakan fungsi trace() yang 

menandakan bahwa DTrace seharusnya merekam arguman 

yang diberikan, string “hello, world”, ketika BEGIN 

probe terpicu dan menampilkannya ke monitor. 

Pernyataan kedua menggunakan fungsi exit() untuk 

menandakan bahwa DTrace seharusnya menghentikan 

proses merunut dan keluar dari perintah dtrace. 

DTrace menyediakan sekumpulan fungsi – fungsi yang 

sangat berguna seperti trace() and exit() untuk 

digunakan didalam progam D. Untuk memanggil sebuah 

fungsi, spesifikasikan namanya diikuti oleh 

argumen-argumennya didalam tanda kurung. Daftar 

lengkap fungsi-fungsi D dijelaskan dalam Solaris 

Dynamic Tracing Guide. 

Sampai disini, mereka yang terbiasa dengan bahasa 

pemograman C, akan menyadari dari nama fungsi dan 

contoh-contoh diatas bahwa bahasa pemograman D yang 

digunakan oleh DTrace sangat mirip dengan C dan 

awk(1). Pada kenyataannya, bahasa D memang berasal 

dari sebagian besar sub-bagian bahasa C yang 

dikombinasikan dengan kumpulan fungsi-fungsi dan 

variabel khusus sehingga membantu memudahkan proses 

merunut. 

Mereka yang sebelumnya pernah membuat program C, 

akan dengan segera mentransfer sebagian besar 

pengetahuan tentang C untuk membuat program tracing 

dalam bahasa D. Untuk mereka yang tidak mengenal 



122


bahasa C, mempelajari bahasa D tetap sangat mudah. 

Langkah pertama yang harus dilakukan adalah 

memahami dengan benar kaidah-kaidahnya dan 

mempelajari lebih dalam bagaimana DTrace bekerja, 

kemudian mempelajari bagaimana membuat program D 

yang lebih menarik 

. 



123

Tujuan 

8M O D U L 

Men-debug Aplikasi dengan 

DTrace 

Tujuan dari modul ini adalah untuk menggunakan 

DTrace untum memonitor kejadian-kejadian tertentu 

dari sebuah aplikasi. 

Sumber Bacaan 

Lain 

Application Packaging Developer’s Guide. 

SunMicrosystems, Inc., 2005. 



124

Mengaktifkan Probe Didalam Moda Pengguna 

Mengaktifkan Probe Didalam Moda 

Pengguna 

DTrace memungkinkan juga untuk secara dinamis 

menambah probe-probe kedalam fungsi-fungsi di 

tingkat pengguna. Kode program pengguna tidak perlu 

untuk dikompilasi-ulang, bendera khusus, atau 

distart-ulang. Probe-probe DTrace dapat dinyalakan 

hanya dengan pemanggilan penyedianya. 

Sebuah deskripsi probe memili kaidah sebagai 

berikut: 

pid:mod:function:name 

pid: format pid processid (contoh pid 5234) 

mod: nama librari atau a.out (biner tereksekusi) 

function: nama fungsi 

name: entry for function entry return for function 

return 



125

Merunut Aplikasi Dengan DTrace 


Didalam latihan ini akan dipelajari bagaimana 

memanfaatkan DTrace untuk merunut sebuah aplikasi. 

Ringkasan 

Lab ini dibuat dengan menggunakan nomor ID proses 

di dalam deskripsi probe untuk merunut aplikasi 

tertentu. Langkah-langkahnya semakin kompleks di 

bagian akhir latihan ini, dengan menambahkan jumlah 

dan kedalaman informasi dari perilaku aplikasi yang 

teramati. 



126


Merunut gcalctool dengan 

DTrace 

1.Dari menu Application atau Program, jalankan 

program kalkulator. 

2.Temukan nomor ID prosesnya. 

# pgrep gcalctool 

8198 

Angka ini adalah nomor ID proses gcalctool, 

selanjutnya akan disebut procid. 

3.Ikuti langkah-langkah berikut untuk membuat skrip 

D yang akan menghitung berapa kali fungsi-fungsi 

tertentu di dalam gcalctool dipanggil. 

a.Dengan editor teks, buat sebuah file bernama 

proc_func.d. 

b.Gunakan pid$1:::entry sebagai deskripsi-probe. 

$1 adalah argumen pertama yang yang diterima oleh 

skrip, biarkan bagian predikat tetap kosong. 

c.Dibagian aksi, tambahkan sebuah fungsi 

pengkumulatif untuk menghitung jumlah total 

berapa kali fungsi-fungsi tertentu dipanggil 

dengan menggunakan aggregate statement 

@[probefunc]=count(). 

pid$1:::entry 

{ 

@[probefunc]=count(); 

} 

d.Jalankan skrip yang baru dituliskan tadi. 

# dtrace -qs proc_func.d procid 

Ganti procid dengan nomor ID proses gcalctool 



127


e.Lakukan sebuah penghitungan di program 

kalkulator. 

f.Tekan Control+C didalam jendela dimana skrip D 

dijalankan. 

Catatan – Skrip DTrace mengumpulkan data secara 

terus menerus hingga diberhentikan dengan menekan 

Control+C. Jika tidak diperlukan untuk menampilkan 

jumlah data total yang dikumpulkan, DTrace tetap 

akan menampilkannya. 

4.Sekarang, modifikasi skripnya sehingga hanya 

menghitung fungsi-fungsi dari librari libc. 

a. Salin file proc_func.d ke proc_libc.d. 

b. Modifikasi deskripsi probe didalam file 

proc_libc.d menjadi seperti berikut: 

pid$1:libc::entry 

c. Skrip barunya akan terlihat seperti 


pid$1:libc::entry 

{ @[probefunc]=count(); 

} 

5.Sekarang jalankan skripnya 

# dtrace -qs proc_libc.d procid 

Ganti procid dengan nomor ID proses gcalctool 

a. Lakukan sebuah perhitungan di kalkulator 

b. Tekan Control+C didalam jendela dimana 

skrip D dijalankan untuk melihat keluarannya. 



128


6.Terakhir, modifikasi skripnya untuk mengetahui 

berapa lama waktu yang diperlukan oleh masingmasing 

fungsi. 

a. Buat sebuah file bernama func_time.d. 

Gunakan dua deskripsi probe didalam func_time.d. 

b. Tuliskan probe pertama seperti berikut: 

pid$1:::entry 

c. Tuliskan probe kedua seperti berikut: 

pid$1:::return 

d. Di bagian aksi dari probe pertama, simpan 

timestamp didalam variabel ts. 

Timestamp adalah sebuah variable yang secara 

internal tersedia (built-in) di DTrace dan 

berfungsi untuk menghitung berapa nanoseconds 

waktu yang diperlukan dari titik tertentu yang 

lampau. 

e. Dibagian aksi dari probe kedua hitung 

berapa nanosecond waktu total yang terlewati: 

@[probefunc]=sum(timestamp - ts) 

f. Skrip func_time.d akan sama dengan yang 


pid$1:::entry 

{ ts = timestamp; 

} 

pid$1:::return /ts/ 

{ @[probefunc]=sum(timestamp - ts); 

} 



129


7.Jalankan skrip func_time.d: 

# dtrace -qs func_time.d procid 

Ganti procid dengan ID prosesnya gcalctool 

a. Lakukan perhitungan dengan kalkulator. 

b. Tekan Control+C di dalam terminal dimana 

skrip D dijalankan untuk melihat keluaran 

perintahnya: 

^C 

gdk_xid__equal 2468 

_XSetLastRequestRead 2998 

_XDeq 3092 

... 

Kolom kiri meperlihatkan nama fungsi dan kolom 

kanan memperlihatkan on waktu yang diperlukan untuk 

fungsi tersebut. Satuan waktunya adalah nano 

seconds. 



130

Tujuan 

9M O D U L 

Men-debug Aplikasi C++ dengan 

DTrace 

Contoh-contoh yang terdapat dalam modul ini 

mendemonstrasikan pemanfaatan DTrace untuk 

mendiagnosa kesalahan-kesalahan pada aplikasi C++. 

Contoh-contoh ini juga digunakan untuk 

membandingkan DTrace dengan peranti pen-debug 

aplikasi yang lain, termasuk perangkat lunak Sun 

Studio 10 dan mdb. 



131

Menggunakan DTrace Untuk Men-debug dan Membuat Profil 

Sebuah Program C++ 

Menggunakan DTrace Untuk Men-debug 

dan Membuat Profil Sebuah Program C+ 

+ 

Sebuah program sampel CCtest dibuat untuk 

mendemostrasikan sebuah kesalahan yang lazim 

terjadi di aplikasi C++ yaitu ketidakcukupan 

memori. Dalam banyak hal, ketidakcukupan memori 

terjadi ketika sebuah obyek dibuat tetapi tidak 

pernah dimusnahkan, dan kasus seperti ini yang ada 

didalam sampel program di modul ini. 

Ketika men-debug sebuah program C++ program, 

perhatikan bahwa kompiler mengkonversi beberapa 

nama dalam C++ menjadi kumpulan karakter dan 

bilangan yang kompleks dan agak susah dipahami. 

Nama-nama yang kompleks ini merupakan sebuah 

rincian implementasi yang diperlukan untuk 

mendukung C++ pemuatan-berlebih (overloading) 

fungsi, untuk menyediakan nama eksternal yang 

berlaku untuk nama fungsi C++ yang terdiri 

karakter-karakter khusus, dan untuk membedakan 

fungsi dan variabel dengan nama yang sama 

dideklarasikan di ruang nama dan kelas yang 

berbeda. 

Contohnya, gunakan nm untuk mengekstraksi tabel 

simbol dari sebuah sampel program yang bernama 

CCtest menampikan keluaran sebagai berikut: 

# /usr/ccs/bin/nm CCtest 

... 

[61] | 134549248| 53|FUNC |GLOB |0 |9 |__1cJTestClass2T5B6M_v_ 

[85] | 134549301| 47|FUNC |GLOB |0 |9 |__1cJTestClass2T6M_v_ 

[76] | 134549136| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t5B6M_v_ 

[62] | 134549173| 71|FUNC |GLOB |0 |9 |__1cJTestClass2t5B6Mpc_v_ 

[64] | 134549136| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t6M_v_ 

[89] | 134549173| 71|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mpc_v_ 

[80] | 134616000| 16|OBJT |GLOB |0 |18 |__1cJTestClassG__vtbl_ 

[91] | 134549348| 16|FUNC |GLOB |0 |9 | 



132



__1cJTestClassJClassName6kM_pc_ 

... 



133



Catatan – Kode pemograman dan makefile untuk CCtest 

tersedia di halaman akhir modul ini. 

Dari keluaran ini, dapat diasumsikan bahwa sejumlah 

simbol-simbol acak yang muncul ketika mendebug 

berhubungan dengan sebuah bernama TestClass, tetapi 

tidak dapat ditentukan apakah simbol-simbol ini 

berhubungan dengan konstruktor, destruktor, or 

fungsi-fungsi kelas. 

Kompiler Sun Studio memasukan piranti berikut, yang 

dapat digunakan untuk menerjemahkan simbo-simbol 

acak ini menjadi simbol-simbol C++ pasangannya, 

yaitu: nm -C, dem, dan c++ filt. 

Catatan – Perangkat lunak Sun Studio 10 digunakan 

disini, tetapi contoh-contoh dalam modul ini juga 

telah ditest oleh Sun Studio 9 and 10. 

Jika aplikasi C++ dikompilasi dengan gcc/g++, 

terdapat pilihan piranti lain untuk menerjemahkan 

symbol-simbol acak dari sebuah aplikasi yang 

dikenali baik oleh Sun Studio dan nama-nama simbol 

GNU, yaitu: gc++filt yang tersedia di /usr/sfw/bin dapat 

digunakan untuk menerjemahkan simbol-simbol yang 

terdapat didalam aplikasi g++. 

Contoh: 

Simbol-simbol Sun Studio tanpa c++filt: 

# nm CCtest | grep TestClass 

[65] | 134549280| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t6M_v_ 

[56] | 134549352| 54|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mi_v_ 

[92] | 134549317| 35|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mpc_v_ 

... 

Simbol-simbol Sun Studio dengan c++filt: 

# nm CCtest | grep TestClass | c++filt 

[65]|134549280| 37|FUNC |GLOB |0 |9 |TestClass::TestClass() 



134



[56]|134549352| 54|FUNC |GLOB |0 |9 |TestClass::TestClass(int) 

[92]|134549317| 35|FUNC |GLOB |0 |9 |TestClass::TestClass(char*) 

... 



135



simbol-simbol g++ tanpa gc++filt: 

[86] | 134550070| 41|FUNC |GLOB |0 |12 |_ZN9TestClassC1EPc 

[110] | 134550180| 68|FUNC |GLOB |0 |12 |_ZN9TestClassC1Ei 

[114] | 134549984| 43|FUNC |GLOB |0 |12 |_ZN9TestClassC1Ev 

... 

simbol-simbol g++ dengan gc++filt: 

# nm gCCtest | grep TestClass | gc++filt 

[86] |134550070|41|FUNC|GLOB |0 |12|TestClass::TestClass(char*) 

[110]|134550180|68|FUNC|GLOB |0 |12|TestClass::TestClass(int) 

[114]|134549984|43|FUNC|GLOB |0 |12|TestClass::TestClass() 

... 

Dan akhirnya, dengan nm –C untuk menampilkan simbolsimbol: 

[64]|134549344|71|FUNC|GLOB|0|9|TestClass::TestClass() 

[__1cJTestClass2t6M_v_] 

[87]|134549424|70|FUNC|GLOB|0|9|TestClass::TestClass(const char*) 

[__1cJTestClass2t6Mpkc_v_] 

[57]|134549504|95|FUNC|GLOB|0|9|TestClass::TestClass(int) 

[__1cJTestClass2t6Mi_v_] 

Berdasarkan informasi-informasi ini bisa dibuatkan 

skrip DTrace untuk melakukan pengumpulan informasi 

(aggregation) terhadap panggilan-panggilan obyek 

yang terkait dengan test program kita. Kita dapat 

menggunakan penyedia pid DTrace untuk mengaktifkan 

probe-probe yang berkaitan dengan simbol-simbol C+ 

+. 

Untuk membuktikan teori konstruktor/destruktor, 

kita mulai dengan menghitung hal-hal berikut: 

Jumlah obyek yang dibuat -- jumlah panggilan ke 

fungsi new() 

Jumlah obyek yang dimusnahkan – jumlah pnggilan 

ke fungsi delete() 

Dengan menggunakan perintah dibawah ini, kita bisa 

mengekstrak simbol-simbol yang berkaitan dengan 

fungsi new() and delete() dari program CCtest: 



136



# dem ‘nm CCtest | awk -F\| ’{ print $NF; }’‘ | egrep "new| 

delete" 

__1c2k6Fpv_v_ == void operator delete(void*) 

__1c2n6FI_pv_ == void*operator new(unsigned) 



137



Skrip DTrace dengan kegunaan yang sama dapat 

digunakan untuk mengaktifkan probe terhadap fungsi 

new() dan delete(), skripnya bernama CCagg.d: 

#!/usr/sbin/dtrace -s 

pid$1::__1c2n6FI_pv_: 

{ 

@n[probefunc] = count(); 

} 

pid$1::__1c2k6Fpv_v_: 

{ 

@d[probefunc] = count(); 

} 

END 

{ 

printa(@n); 

printa(@d); 

} 

Jalankan program CCtest didalam sebuah jendela, 

kemudian eksekusi skrip CCagg.d di jendela yang lain 

seperti diperlihatkan berikut ini: 

# dtrace -s ./CCagg.d ‘pgrep CCtest‘ | c++filt 

Keluaran DTrace diteruskan dan menjadi masukan bagi 

c++filt untuk diterjemahkan menjadi simbol-simbol C+ 

+, tetapi gunakan perintah ini dengan hati-hati 

seperti tertulis dalam peringatan berikut ini. 

Perhatian – Jangan gunakan ^C untuk keluar dari 

perintah DTrace seperti yang biasa dilakukan karena 

hal ini menyebabkan c++filt ikut berhenti bersama 

dengan DTrace sehingga tidak ada keluaran yang 

ditampilkan. 



138



Untuk menampilkan keluaran perintah ini, buka 

jendela baru dan ketikan perintah: 

# pkill dtrace 

Gunakan urutan langkah-langkah berikut sebagai 

lanjutan latihan ini: 

Jendela 1: 

# ./CCtest 

Jendela 2: 

# dtrace -s scriptname | c++filt 

Jendela 3: 


Keluaran di jendela 2 menampilkan jumlah total 

panggilan terhadap fungsi new() dan delete() 

seperti berikut ini: 

void*operator new(unsigned) 12 

void operator delete(void*) 8 

Dari pengamatan keluaran diatas, terlihat memang 

benar dugaan bahwa lebih banyak obyek-obyek yang 

dibuat daripada yang dihapus. 

Berikutnya adalah memeriksa alamat memori obyek 

tersebut dan dan mencoba untuk mencocokannya dengan 

setiap keberadaan fungsi new() and delete(). Variabel 

argumen DTrace digunakan untuk menampilkan setiap 

alamat yang berkaitan dengan obyek. 

Karena sebuah pointer ke obyek tertentu terdapat 

didalam nilai balik fungsi new(), seharusnya akan 

terdapat nilai pointer yang sama sebagai arg0 dalam 

panggilan terhadap fungsi delete(). 



139



Dengan sedikit modifikasi pada skrip sebelumnya, 

jadilah sebuah skrip baru bernama CCaddr.d: 


#pragma D option quiet 

/* 



*/ 

/* return from new() */ 

pid$1::__1c2n6FI_pv_:return 

{ 

printf("%s: %x\n", probefunc, arg1); 

} 

/* call to delete() */ pid$1::__1c2k6Fpv_v_:entry 

{ 


} 

Eksekusi skrip ini: 

# dtrace -s ./CCaddr.d ‘pgrep CCtest‘ | c++filt 

Tunggu sejenak, kemudian ketikan perintah berikut 

didalam jendela 3: 


Keluarannya memperlihatkan sebuah pola berulang 

berikut, sebanyak tiga panggilan terhadap fungsi 

new() dan dua panggilan terhadap fungsi delete(): 

void*operator new(unsigned): 809e480 

void*operator new(unsigned): 8068a70 

void*operator new(unsigned): 809e4a0 

void operator delete(void*): 8068a70 

void operator delete(void*): 809e4a0 

Dari hasil pengamatan terhadap keluaran yang 

berulang ini, sebuah pola menarik muncul. Terlihat 

bahwa setiap panggilan pertama terhadap fungsi new() 

tidak memiliki panggilan delete() yang terkaitnya. 

Disini sekarang sumber penyebab ketidakcukupan 

memori dapat teridentifikasi! 



140



Dengan melanjutkan pengamatan menggunakan DTrace, 

informasi lain masih dapat diperoleh. Dengan 

memodifikasi skrip sebelumnya, dapat diketahui tipe 

kelas yang berkaitan dengan obyek yang dibuat di 

alamat 809e480 dan panggilan terhadap ustack() untuk 

fungsi new(). Skrip hasil modifikasi ini bernama 

CCstack.d: 


#pragma D option quiet 

/* 



*/ 

pid$1::__1c2n6FI_pv_:entry 

{ 

ustack(); 

} 

pid$1::__1c2n6FI_pv_:return 

{ 


} 

pid$1::__1c2k6Fpv_v_:entry 

{ 


} 

Eksekusi CCstack.d di jendela 2, kemudian ketikan 

pkill dtrace di jendela 3 untuk menampilkan keluaran 

berikut: 

# dtrace -s ./CCstack.d ‘pgrep CCtest‘ | c++filt 

libCrun.so.1‘void*operator new(unsigned) 

CCtest‘main+0x19 

CCtest‘0x8050cda 

void*operator new(unsigned): 80a2bd0 


CCtest‘main+0x57 


void*operator new(unsigned): 8068a70 


CCtest‘main+0x9a 


void*operator new(unsigned): 80a2bf0 



141



void operator delete(void*): 8068a70 

void operator delete(void*): 80a2bf0 



142



Berdasarkan data dari fungsi ustack() diperoleh 

informasi bahwa fungsi new() dipanggil dari main+0x19, 

main+0x57, dan main+0x9a. Pengamatan berikutnya lebih 

ditujukan pada obyek yang berkaitan dengan 

panggilan pertama terhadap fungsi new() di main+0x19. 

Untuk menentukan tipe konstruktor yang dipanggil di 

main+0x19, manfaatkan mdb seperti berikut ini: 

# gcore ‘pgrep CCtest‘ 

gcore: core.1478 dumped 

# mdb core.1478 

Loading modules: [ libc.so.1 ld.so.1 ] 

> main::dis 

main: pushl %ebp 

main+1: movl %esp,%ebp 

main+3: subl $0x38,%esp 

main+6: movl %esp,-0x2c(%ebp) 

main+9: movl %ebx,-0x30(%ebp) 

main+0xc: movl %esi,-0x34(%ebp) 

main+0xf: movl %edi,-0x38(%ebp) 

main+0x12: pushl $0x8 

main+0x14: call -0x2e4 

main+0x19: addl $0x4,%esp 

main+0x1c: movl %eax,-0x10(%ebp) 

main+0x1f: movl -0x10(%ebp),%eax 

main+0x22: pushl %eax 

main+0x23: call +0x1d5 

... 

Sebuah konstruktor dipanggil setelah panggilan 

terhadap fungsi new(), di alamat main+0x23. Panggilan 

ini teridentifikasi sebagai panggilan terhadap 

konstruktor __1cJTestClass2t5B6M_v_ dan panggilan ini 

tidak pernah dimusnahkan. Manfaatkan dem untuk 

menerjemahkan simbol ini: 

# dem __1cJTestClass2t5B6M_v_ 

__1cJTestClass2t5B6M_v_ == TestClass::TestClass #Nvariant 1() 

Dapat disimpulkan bahwa panggilan terhadap 

TestClass() baru di main+0x19 adalah penyebab 

terjadinya kekurangcukupan memori. 



143



Pengamatan terhadap file kode pemograman CCtest.cc 

memperlihatkan: 

... 

t = new TestClass(); 

cout ClassName(); 

t = new TestClass((const char *)"Hello."); 


tt = new TestClass((const char *)"Goodbye."); 


delete(t); 

delete(tt); 

... 

Jelas terlihat bahwa pemakaian pertama kali 

variabel t = new TestClass(); ditulis-ulangkan oleh 

pemakain kedua: t = new TestClass((const char *)"Hello.");. 

Ketidakcukupan memori telah teridentifikasi dan 

perbaikan bisa diimplementasikan. 

Penyedia pid DTrace pid memungkinkan pengaktifan 

probe terhadap sembarang instruksi yang berkaitan 

dengan sebuah proses yang akan diamati. Contoh ini 

ditujukan untuk membuat sebuah model pendekatan 

DTrace untuk secara interaktif men-debug proses. 

Fitur-fitur DTrace yang digunakan dalam contoh ini 

meliputi: pengumpulan informasi (aggregations), 

menampilkan argumen-arguman fungsi dan nilai balik 

dan mengamati tumpukan panggilan pengguna (user 

call stack). 

Penggunaan perintah c++filt dari perangkat lunak Sun 

Studio dan gc++filt dari gcc adalah untuk mengekstrak 

probe-probe fungsi dari tabel simbol sebuah program 

dan menampilkan keluaran DTrace dalam format yang 

sesuai dengan kode pemogramannya. 



144



File-file kode pemograman yang dibuat untuk contoh 

ini adalah sebagai berikut: 

CONTOH 9–1 TestClass.h 

class TestClass 

{ 

public: 

TestClass(); 

TestClass(const char *name); 

TestClass(int i); 

virtual ~TestClass(); 

virtual char *ClassName() const; 

private: 

char *str; 

}; 

TestClass.cc: 

#include 

#include 

#include 

#include 

#include "TestClass.h" 

TestClass::TestClass() { 

str=strdup("empty."); 

} 

TestClass::TestClass(const char *name) { 

str=strdup(name); 

} 

TestClass::TestClass(int i) { 

str=(char *)malloc(128); 

sprintf(str, "Integer = %d", i); 

} 

TestClass::~TestClass() { 

if ( str ) 

free(str); 

} 

char *TestClass::ClassName() const { 

return str; 

} 



145



CONTOH 9–2 CCtest.cc 

#include 

#include 

#include 

#include 

#include "TestClass.h" 

int main(int argc, char **argv) 

{ 

TestClass *t; 

TestClass *tt; 

while (1) { 

t = new TestClass(); 


t = new TestClass((const char *)"Hello."); 


tt = new TestClass((const char *)"Goodbye."); 


delete(t); 

delete(tt); 

sleep(1); 

} 

} 

CONTOH 9–3 Makefile 

OBJS=CCtest.o TestClass.o 

PROGS=CCtest 

CC=CC 

all: $(PROGS) 

echo "Done." 

clean: 

rm $(OBJS) $(PROGS) 

CCtest: $(OBJS) 

$(CC) -o CCtest $(OBJS) 

.cc.o: 

$(CC) $(CFLAGS) -c $< 



146

Tujuan 

1M O D U L 

Manajemen Memori dengan 

DTrace dan MDB 

Didalam module ini akan dibahas bagaimana kita 

dapat menyusun kembali pengetahuan yang telah 

diperoleh tentang pengamatan proses dengan DTrace 

untuk melakukan pengujian kegagalan halaman memori 

(page fault). Kemudian pengujian ini diteruskan 

dengan menggunakan MDB. MDB merupakan piranti pendebug 

tingkat-dasar yang memungkinkan untuk 

pencarian kesalahan hingga ke tingkat kode 

pemogramannya. 

Sumber Bacaan 

Lain 

SolarisModular Debugger Guide SunMicrosystems, 

Inc., 2007. 



147

Perangkat Lunak Untuk Manajemen Memori 

Perangkat lunak Untuk Manajemen 

Memori 

Manajemen memori di OpenSolaris menggunakan suatu 

konstruksi perangkat lunak yang disebut segmen 

untuk menangani memori virtual sebuah proses juga 

kernel. Sebagian besar struktur data yang digunakan 

oleh perangkat lunak manajemen memori ini 

didefinisikan di /usr/include/vm/*.h. Di dalam modul 

ini, akan dipelajari kode pemograman dan struktur 

data yang digunakan untuk menangani kegagalan 

halaman memori. 



148

Pengujian Memori Virtual dengan DTrace dan MDB 

Pengujian Memori Virtual dengan 

DTrace dan MDB 

Tujuan dari lab ini adalah untuk menguji kegagalan 

halaman memori dengan menggunakan DTrace dan MDB. 

Ringkasan 

Pertama, skrip DTrace digunakan untuk merunut aksiaksi 

dari sebuah kegagalan halaman memori tunggal 

untuk sebuah proses. Skrip ini menampilkan alamat 

memori virtual yang menyebabkan suatu kegagalan, 

dan kemudian merunut setiap fungsi yang dipanggil 

terhitung dari waktu kegagalan halaman memori 

terjadi hingga program kernel yang berfungsi 

menangani kegagalan virtual memori (fault handler) 

kembali. Dari pengamatan terhadap keluaran skrip 

ini dapat ditentukan bagian mana dari sumber kode 

pemograman yang harus diperiksa lebih lanjut. 

Catatan- Didalam modul ini, telah ditambahkan teks 

informasi keterangan dari keluaran skrip DTrace, 

yang sebagian besar berupa kode-kode, untuk 

membimbing latihan ini. Perhatikan simbol


Pengujian Kegagalan Halaman 

Memori Dari Sebuah Proses 

Dengan DTrace 

1.Buka sebuah jendela terminal 

2.Buatlah sebuah skrip DTrace bernama pagefault.d 

seperti berikut ini: 


#pragma D option flowindent 

pagefault:entry 

/execname == $$1/ 

{ 

printf("fault occurred on address = %p\n", args[0]); 

self->in = 1; 

} 

pagefault:return 

/self->in == 1/ 

{ 

self->in = 0; 

exit(0); 

} 

entry 

/self->in == 1/ 

{ 

} 

return 

/self->in == 1/ 

{ 

} 

3.Jalan skrip ini dengan Mozilla sebagai 

argumennya. 

Catatan – File yang dieksekusi untuk menjalankan 

Mozilla adalah mozilla-bin bukan mozilla. 

Pernyataan dengan penekanan tertentu juga 

digunakan untuk menampilkan berbagai macam 

panggilan, sebagai contoh adalah panggilan 

terhadap mutex_owner(), dengan menggunakan 

ASSERT().Pernyataan dengan penekanan tertentu hanya 

digunakan untuk men-debug kernel. 



150


# ./pagefault.d mozilla-bin 

dtrace: script ’./pagefault.d’ matched 42626 probes 

CPU FUNCTION 

0 -> pagefault fault occurred on address = fb985ea2 

0 | pagefault:entry as_fault as_segat 

0 -> avl_find as_segcompar


0 -> hat_probe hat_kpm_pfn2va 

0


0 -> fop_getpage ufs_getpage bmap_has_holes


0


0 -> lufs_read_strategy bdev_strategy cmdkstrategy 


(thread 

0


0 -> pageio_done


# 



158


Perhatikan bahwa keluaran diatas sebenarnya sudah 

diperpendek untuk kemudahan pemahaman. Pada 

tingkat atas, ketika terjadi kegagalan halaman 

memori hal-hal berikut akan terjadi: 

Rutin pagefault() dipanggil untuk menangani 

kegagalan halaman memori s. 

Rutin pagefault() memanggil as_fault() untuk 

menangani kegagalan pada sebuah alamat 

memori 

Rutin as_fault() menyusuri susunan AVL dari 

struktur seg untuk melakukan pencarian segmen 

dengan alamat yang salah. Jika tidak 

ditemukan segmen seperti ini, proses yang 

bersangkutan akan mengirimkan sebuah sinyal 

SIGSEGV (segmentation violation). 

Jika segmen dengan alamat yang salah 

ditemukan, sebuah program kernel fault 

handler yang spesifik segmen dipanggil. Nama 

fault handler ini adalah segvn_fault() yang 

digunakan oleh sebagian besar segmen. 

segvn_fault() mencari apakah lokasi memori yang 

salah telah dipakai sebelumnya oleh proses 

yang bersangkutan. Jika data dilokasi memori 

tersebut masih ada (tetapi sudah dinyatakan 

bebas oleh pemindai halaman memori - memori 

page scanner), lokasi tersebut akan “diklaim 

ulang” sehingga dikeluarkan daftar lokasi 

yang bebas. Jika lokasi di memori beserta 

datanya sudah tidak ditemukan lagi maka akan 

dipanggil ufs_getpage(). 

ufs_getpage() berusaha menemukan nomor blok 

didalam sistem file dari data yang semula 

ada di lokasi memori dengan memanggil 

bmap_read(). 

Selanjutnya dipanggil rutin strategi program 

penggerak perangkat untuk menentukan rutin 



159


strategi apa yang akan dilakukan, lihat 

lebih lanjut dimanual strategy(9E). 

Selama lokasi memori sedang dibaca, thread 

yang menyebabkan kegagalan halaman memori 

blocks akan di-switch out melalui panggilan 

swtch(). Ini memberi kesempatan thread yang 

lain untuk aktif. 



160


Ketika paging I/O telah lengkap, interrupt 

handler dari penggerak disk akan 

membangunkan thread mozilla-bin yang semula 

terblok. 

Program penggerak disk kembali melalui kode 

sistem file kepada segvn_fault(). 

segvn_fault() kemudian memanggil segvn_faultpage(). 

segvn_faultpage() memanggil lapisan HAT 

(Hardware Address Translation) untuk mengisi 

page table entry(s) (PTE)s dari lokasi 

memori tadi. 

Sampai disini, alamat memori virtual yang 

menyebabkan kegagalan halaman memori 

sekarang sudah dipetakan kembali dengan 

lokasi fisik memori yang benar. Ketika 

pagefault() kembali, instruksi-instruksi yang 

semula menyebabkan kegagalan halaman memori 

akan dijalankan ulang dan seharusnya akan 

diselesaikan dengan benar. 

4.Memanfaatkan mdb untuk mengamati struktur data 

kernel dan menentukan lokasi memori fisik yang 

berhubungan dengan terjadinya kegagalan halaman 

memori di memori virtual: 

a.Bukan jendela terminal 

b.Hitung banyaknya segmen yang digunakan oleh 

mozilla menggunakan perintah pmap seperti 


# pmap -x ‘pgrep mozilla-bin‘ | wc 

368 2730 23105 

# 

Keluarannya memperlihatkan terdapat 368 segmen. 

Catatan – Dari pencarian terhadap segmen yang 

mengandung kegagalan alamat memori ditemukan 

segmen-segmen yang benar setelah 8 segmen. 



161


Perhatikan panggilan ke as_segcompar dari keluaran DTrace 

diatas. Terbukti, penggunaan struktur AVL dapat 

mempersingkat pencarian! 



162


c.Gunakan mdb untuk menemukan lokasi segmen 

dengan fault address. 

Catatan – Jika diinginkan untuk menyimpan setiap 

aktivitas didalam mdb, gunakan perintah: ::log 

/tmp/logfile diikuti oleh perintah !vi /tmp/logfile 

untuk memulai menyimpannya. Jika tidak, jalankan 

jalankan saja mdb didalam penyangga editor. 

# mdb -k 

Loading modules: [ unix krtld genunix specfs dtrace 

ufs ip sctp usba random fctl s1394 

nca lofs crypto nfs audiosup sppp cpc fcip ptm ipc ] 

> ::ps !grep mozilla-bin ffffffff81d6a040::print proc_t p_as | ::walk seg | ::print 

struct seg 

 

{ 

s_base = 0xfb800000


} 

s_data = 0xffffffff82d85070 

 



164


> ffffffff82d85070::print segvn_data_t


> ffffffff82f9e480::print vnode_t v_path 

v_path = 0xffffffff82f71090 

"/usr/sfw/lib/mozilla/components/libgklayout.so" 

> fb985ea2-fb800000=K


> ffffffff82f9e480::walk page | ::print page_t


 



168


> bd62*1000=K


> ffffffff81d6a040::context fb985ea2,10/ai ffffffff81d6a040::print proc_t p_as fb985ea2::vtop -a ffffffff828b61d0


sesuai 



171


Begitu segmen yang mengalami kegagalan ditemukan, 

isi struktur data segvn_data langsung ditampilkan. 

Didalam segmen ini, sebuah vnode_t memetakan data 

segmennya. Dilanjutkan dengan pencarian lokasi 

halaman memori yang berhubungan dengan alamat 

didalam segmen tersebut. 

Begitu lokasi page_t ditemukan, sebuah nomor frame 

halaman diperoleh. Kemudian nomor page frame 

dikonversikan menjadi sebuah alamat fisik diikuti 

dengan pengujian beberapa data di alamat fisik 

tersebut. Berikutnya mengeluarkan data ini 

sebagai kode. Terakhir melakukan pengecekan 

terhadap alamat fisik dengan perintah mdb bernama 

vtop (virtual-to-physical). 

d.Keuntungan tambahan: dengan menyusuri table 

page dari suatu proses dapat dilihat bagaimana 

sebuah alamat virtual diterjemahkan ke alamat 

fisiknya. 



172

Tujuan 

1M O D U L 

Men-debug Program Penggerak 

Perangkat Dengan DTrace 

Tujuan dari modul ini adalah untuk mempelajari 

bagaimana menggunakan DTrace untuk men-debug proyek 

pengembangan program penggerak perangkat tertentu 

dengan menggunakan sebuah studi kasus. 



173

Membuat Program Penggerak smbfs dari Linux ke Solaris OS 

Memindahkan Program Penggerak smbfs 

Dari Linux Ke Solaris OS 

Studi kasus ini memfokuskan pada pemakaian secara 

optimal kemampuan DTrace unutk membantu 

pengembangan program penggerak perangkat. 

Jauh sebelum ada DTrace, untuk men-debug program 

penggerak perangkat seorang pengembang menggunakan 

panggilan fungsi seperti cmn_err() yang akan me-log 

informasi diagnosa ke file /var/adm/messages. 

Proses yang merepotkan ini bersifat spekulatif, 

memerlukan kompilasi ulang dan reboot sistem untuk 

menemukan kesalahan kode pemograman sebuah 

perangkat lunak. Pengembang dengan bakat bahasa 

assembler-nya dapat menggunakan adb dan membuat 

modul mdb yang diperlukan dalam bahasa C untuk 

mendiagnosa kesalahan perangkat lunak. Namun, 

pendekatan lama untuk pengembangan dan men-debug 

kernel seperti ini menghabiskan waktu yang cukup 

lama. 

DTrace menyediakan sebuah cara diagnosa yang 

praktis. Daripada melakukan penulusuran file 

/var/adm/messages atau informasi keluaran perintah 

truss, DTrace dapat digunakan untuk menangkap 

informasi hanya untuk kejadian tertentu yang ingin 

diamati oleh pengembang. Seberapa besar manfaat 

yang bisa diperoleh dari penggunaan DTrace bisa 

dibuktikan melalui beberapa contoh yang sederhana 

berikut. 

Program penggerak yang digunakan sebagai materi 

studi kasus dalam modul ini adalah program 

penggerak smbfs yang telah dibuat berdasarkan model 

program penggerak nfs milik Sun. Diasumsikan program 

penggerak telah berhasil dikompilasi, langkah 

berikutnya adalah melakukan pengujian apakah 

program penggerak tersebut bisa dimuat dan 



174


dibongkar-muat secara benar. Hal pertama yang harus 

dilakukan adalah menyalin program penggerak 

tersebut ke /usr/kernel/fs dan cobalah memuatnya 

secara manual dengan perintah modload: 

# modload /usr/kernel/fs/smbfs 

can’t load module: Out of memory or no room in system tables 



175


Dan di dalam file /var/adm/messages terdapat informasi: 

genunix: [ID 104096 kern.warning] WARNING: system call missing 

from bind file 

Setelah pencarian informasi lebih lanjut dari pesan 

kesalahan “system call missing”, disimpulkan bahwa 

pesan kesalahan ini muncul karena fungsi 

mod_getsysent() didalam file modconf.c gagal memanggil 

fungsi mod_getsysnum. 

Daripada secara manual mengikuti alur program dari 

fungsi mod_getsysnum() dari satu file kode pemograman 

ke file kode pemograman yang lain, skrip DTrace 

yang sederhana berikut ini digunakan untuk 

mengaktifkan semua informasi dan kejadian balik 

dari penyedia fbt (Function Boundary Tracing) setiap 

kali mod_getsynum() dipanggil. 



fbt::mod_getsysnum:entry 

/execname == "modload"/ 

{ 

self->follow = 1; 

} 

fbt::mod_getsysnum:return 

{ 


trace(arg1); 

} 

fbt:::entry 

/self->follow/ 

{ 

} 

fbt:::return 


{ 

trace(arg1); 

} 

Catatan – trace(arg1) menampilkan nilai balik dari 

sebuah fungsi tertentu. 



176


Dengan mengeksekusi skrip ini dan menjalankan 

perintah modload di jendela yang lain diperoleh 

keluaran sebagai berikut: 

# ./mod_getsysnum.d 

dtrace: script ’./mod_getsysnum.d’ matched 35750 probes 

CPU FUNCTION 

0 -> mod_getsysnum 

0 -> find_mbind 

0 -> nm_hash 

0 strcmp 

0 strcmp 

0


Berikut adalah hasil keluarannya setelah dicoba 

lagi untuk memuat program penggerak smbfs: 

# ./mod_getsysnum.d 

dtrace: script ’./mod_getsysnum.d’ matched 35751 probes 

CPU FUNCTION 

0 -> mod_getsysnum 

0 -> find_mbind 

0 -> nm_hash 

0 strcmp 

0 | strcmp:entry name:smbfs, 

hash:timer_getoverrun 

0 strcmp 

0 | strcmp:entry name:smbfs, 

hash:lwp_sema_post 

0


Berikutnya tambahkan isian baru di file 

/etc/name_to_sysnum seperti berikut ini dan kemudian 

lakukan reboot. 

’smbfs 177’ 

Catatan - Fungsi read_binding_file() hanya membaca 

sekali saja file konfigurasi tersebut pada saat 

boot. 

Setelah proses reboot selesai program penggerak 

smbfs berhasil dimuatkan. 

# modload /usr/kernel/fs/smbfs 

Periksa lagi apakah program penggerak tersebut 

telah dimuat dengan perintah modinfo: 

# modinfo | grep smbfs 

160 feb21a58 351ac 177 1 smbfs (SMBFS syscall,client,comm) 

160 feb21a58 351ac 24 1 smbfs (network filesystem) 

160 feb21a58 351ac 25 1 smbfs (network filesystem version 2) 

160 feb21a58 351ac 26 1 smbfs (network filesystem version 3) 

Catatan – Diingatkan kembali bahwa program 

penggerak ini dibuat dengan meniru model program 

penggerak nfs, ini menjelaskan mengapa keluarannya 

menjadi seperti diatas. 

Lanjutkan, dengan mencoba untuk membongkat-muat 

modul tersebut: 

# modunload -i 160 

can’t unload the module: Device busy 

Nampaknya kesalahan ini disebabkan oleh adanya 

nilai balik errno EBUSY. Pengamatan menjadi lebih 

mudah karena program penggerak smbfs adalah sebuah 

modul yang telah termuat sehingga semua fungsi 

smbfs dapat diakses: 

# dtrace -l fbt:smbfs:: | wc -l 

1002 



179


Ini luar biasa! Tanpa menggunakan kode pemograman 

khusus sebanyak 1002 fungsi dan kejadian balik 

dalam sebuah program penggerak dapat diakses. 

Dengan memanfaatkan akses fungsi sebanyak 1002 ini 

pekerjaan men-debug program penggerak dapat 

dilakukan tanpa memerlukan versi 'kode 

terinstrumentasi' khusus! 

Dengan menggunakan skrip DTrace sederhana berikut 

ini, pengamatan terhadap semua panggilan smbfs 

ketika perintah modunload dijalankan dapat dilakukan: 



fbt:smbfs::entry 

{ 

} 

fbt:smbfs::return 

{ 

trace(arg1); 

} 

Nampaknya kode-kode smbfs tidak dapat diakses oleh 

modunload. Berikutnya, gunakan skrip DTrace berikut 

ini untuk pengamatan terhadap modunload: 



fbt::modunload:entry 

{ 


trace(execname); 

trace(arg0); 

} 

fbt::modunload:return 

{ 


trace(arg1); 

} 

fbt:::entry 


{ 

} 

fbt:::return 




180


{ 

trace(arg1); 

} 



181


Keluaran skrip ini adalah sebagai berikut: 

# ./modunload.d 

dtrace: script ’./modunload.d’ matched 36695 probes 

CPU FUNCTION 

0 -> modunload modunload 160 

0 | modunload:entry 

0 -> mod_hold_by_id 

0 -> mod_circdep 

0 mod_hold_by_modctl 

0 mod_release 

0 mod_nenabled != 0) 

return (EBUSY); 

2. if ( detach_driver(mp->mod_modname) != 0 ) return (EBUSY); 

3. if ( kobj_lookup(mp->mod_mp, "_fini") == NULL ) 

4. A failed call to smbfs _fini() routine 



182


Akses langsung ke semua kemungkinan lokasi ini 

tidak dapat dilakukan, tetapi pendekatan terhadap 

lokasi-lokasi ini dapat dilakukan dengan sebuah 

proses pengeliminasian. Dengan skrip berikut ini 

dapat ditampilkan isi dari berbagai struktur dan 

nilai balik didalam moduninstall: 



fbt::moduninstall:entry 

{ 


printf("mod_prim:%d\n", 

((struct modctl *)arg0)->mod_prim); 

printf("mod_ref:%d\n", 

((struct modctl *)arg0)->mod_ref); 

printf("mod_nenabled:%d\n", 

((struct modctl *)arg0)->mod_nenabled); 

printf("mod_loadflags:%d\n", 

((struct modctl *)arg0)->mod_loadflags); 

} 

fbt::moduninstall:return 

{ 


trace(arg1); 

} 

fbt::kobj_lookup:entry 


{ 

} 

fbt::kobj_lookup:return 


{ 

trace(arg1); 

} 

fbt::detach_driver:entry 


{ 

} 

fbt::detach_driver:return 


{ 

trace(arg1); 

} 



183


Skrip ini menghasilkan keluaran seperti berikut 


# ./moduninstall.d 

dtrace: script ’./moduninstall.d’ matched 6 probes 

CPU FUNCTION 

0 -> moduninstall 

mod_prim:0 

mod_ref:0 

mod_nenabled:0 

mod_loadflags:1 

0 -> detach_driver 

0 kobj_lookup 

0


satu dari sekian banyak penyedia DTrace. 



185

A 

A 

AA P P E N D I X 

Sumber Bacaan Tambahan 

OpenSolaris 

Untuk mendapat informasi lebih lanjut, dukungan dan 

training manfaatkan situs-situs berikut ini: 

Dokumentasi Komunitas —http://opensolaris.org/os/ 

community/documentation 

Dokumentasi Sun — 

http://www.sun.com/documentation 

Dukungan Sun — http://www.sun.com/support 

Pelatihan Sun — Sun menawarkan berbagai pelatihan 

Solaris profesional dengan cakupan yang lengkap 

dan pilihan sertifikasi untuk membantu anda 

mengaplikasi platform yang bertenaga ini demi 

kesuksekan yang lebih besar kegiatan anda. Untuk 

mendapat informasi lebih lanjut tentang pelatihan 

Solaris, kunjungi situs ini: 

http://www.sun.com/training/catalog/operating_sys 

tems/index.xml 



186

download dengan klik link ini - Komputasi

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?