OS: Linux Kernel - Revision history

Onnowpurbo: /* Bagaimana Kernel Melihar Proses */

2013-05-15T08:12:50Z

Bagaimana Kernel Melihar Proses

Onnowpurbo: /* Pranala Menarik */

2013-04-07T06:40:56Z

Pranala Menarik

Onnowpurbo: /* Pranala Menarik */

2013-04-03T04:04:27Z

Pranala Menarik

Onnowpurbo: /* Pranala Menarik */

2013-03-21T13:17:11Z

Pranala Menarik

Onnowpurbo: /* Pranala Menarik */

2013-03-20T22:29:56Z

Pranala Menarik

Onnowpurbo: /* Tour Linux Kernel Source */

2013-03-14T08:59:00Z

Tour Linux Kernel Source

Onnowpurbo at 08:58, 14 March 2013

2013-03-14T08:58:20Z

Onnowpurbo: /* ioctl() dari device */

2013-03-14T08:56:29Z

ioctl() dari device

Onnowpurbo: /* ioctl() dari device */

2013-03-14T08:06:22Z

ioctl() dari device

Onnowpurbo: /* ioctl() dari device */

2013-03-14T08:04:59Z

ioctl() dari device

@@ Line 60: / Line 60: @@
 Karena kernel bertanggung jawab untuk memberikan layanan, pembahasan ini akan dilanjutkan dengan melihat pada layanan tersebut (yaitu "system calls"), juga memberikan gambaran umum tentang struktur data di bawahnya maupun organisasi dari code.
-===Bagaimana Kernel Melihar Proses===
+===Bagaimana Kernel Melihat Proses===
 Dari sudut pandang kernel, sebuah proses tidak lebih dari sebuah entry pada tabel proses.

@@ Line 247: / Line 247: @@
 * [[Linux]]
 * [[Ubuntu]]
 * [[Linux: CLI untuk Survival]]
-* [[Sistem Operasi]]
+* [[Linux: Skema Partisi di Linux]]
 * [[Linux: Instalasi Sistem Operasi]]
-* [[Linux: Skema Partisi di Linux]]
 * [[Kernel]]
 * [[Compile Kernel]]
 * [[Compile Kernel: Konfigurasi Kernel]]
-* [[Kernel: Anatomi Kernel Source]]
-* [[OS: Linux Kernel]]
+===Remaster Linux===
 * [[OS: Parameter Kernel Default]]
 * [[OS: Kernel Scheduler]]
 * [[OS: Complete Teori Tuning Kernel Scheduler]]
 * [[OS: Complete Teori Tuning I/O Performance]]
 * [[OS: Tuning Manajemen Memory]]
-* [[OS: Tuning Kernel Scheduler]]
-* [[OS: Tuning Completely Fair Queueing CFQ I/O scheduler]]
+===Android===
-* [[OS: Tuning Completely Fair scheduler CFS]]
 * [[OS: Build in Monitoring Tool]]
 * [[Linux Benchmarking]]
 * [[OS: Benchmarking menggunakan UnixBench]]
 * [[OS: Benchmarking menggunakan LLCBench]]

@@ Line 247: / Line 247: @@
 * [[Linux]]
 * [[Ubuntu]]
 * [[Sistem Operasi]]
 * [[Kernel]]
 * [[Compile Kernel]]
@@ Line 257: / Line 260: @@
 * [[OS: Complete Teori Tuning Kernel Scheduler]]
 * [[OS: Complete Teori Tuning I/O Performance]]
 * [[OS: Tuning Kernel Scheduler]]
 * [[OS: Tuning Completely Fair Queueing CFQ I/O scheduler]]
@@ Line 266: / Line 270: @@
 * [[OS: Mengerti System Call]]
 * [[OS: Membuat Kernel Modul]]

@@ Line 250: / Line 250: @@
 * [[Kernel]]
 * [[Compile Kernel]]
 * [[OS: Linux Kernel]]
 * [[OS: Parameter Kernel Default]]
@@ Line 262: / Line 264: @@
 * [[OS: Benchmarking menggunakan UnixBench]]
 * [[OS: Benchmarking menggunakan LLCBench]]
 * [[OS: Membuat Kernel Modul]]

@@ Line 248: / Line 248: @@
 * [[Ubuntu]]
 * [[Sistem Operasi]]
 * [[OS: Linux Kernel]]
 * [[OS: Parameter Kernel Default]]
 * [[OS: Kernel Scheduler]]
 * [[OS: Complete Teori Tuning Kernel Scheduler]]
 * [[OS: Tuning Kernel Scheduler]]
 * [[OS: Tuning Completely Fair Queueing CFQ I/O scheduler]]
@@ Line 259: / Line 262: @@
 * [[OS: Benchmarking menggunakan UnixBench]]
 * [[OS: Benchmarking menggunakan LLCBench]]

@@ Line 9: / Line 9: @@
 Oleh Alessandro Rubini, rubini@pop.systemy.it
-Bagian ini mencoba untuk menjelaskan source code Linux secara teratur, mencoba membantu pembaca untuk mencapai pemahaman yang baik tentang bagaimana source code diletakkan dan bagaimana fitur unix yang paling relevan diimplementasikan. Targetnya adalah untuk membantu programmer C berpengalaman yang tidak terbiasa dengan Linux dalam mendapatkan akrab dengan desain Linux secara keseluruhan. Itulah sebabnya entry point yang dipilih untuk tur kernel adalah entry point kernel sendiri: sistem boot.
+Bagian ini mencoba untuk menjelaskan [[source code]] [[Linux]] secara teratur, mencoba membantu pembaca untuk mencapai pemahaman yang baik tentang bagaimana [[source code]] diletakkan dan bagaimana fitur unix yang paling relevan diimplementasikan. Targetnya adalah untuk membantu programmer C berpengalaman yang tidak terbiasa dengan [[Linux]] dalam mendapatkan akrab dengan desain Linux secara keseluruhan. Itulah sebabnya entry point yang dipilih untuk tur kernel adalah entry point kernel sendiri: sistem boot.
 Pemahaman yang baik tentang bahasa C diperlukan untuk memahami materi, serta familiar dengan konsep Unix dan arsitektur PC. Namun, tidak ada kode C akan muncul dalam bagian ini, melainkan pointer ke source code sebenarnya. Bagian ini cenderung untuk memberikan gambaran informal.

@@ Line 1: / Line 1: @@
-Sebuah kernel UNIX adalah interpreter yang menerjemahkan panggilan system call tingkat pengguna akses yang disinkronisasi ke hardware dan device driver. Panggilan didefinisikan oleh standar POSIX.
+Sebuah kernel [[UNIX]] adalah [[interpreter]] yang menerjemahkan panggilan system call tingkat pengguna akses yang disinkronisasi ke [[hardware]] dan [[device driver]]. Panggilan didefinisikan oleh standar [[POSIX]].
-Interpreter mengelola permintaan system call tingkat pengguna untuk mengakses file atau proses. Kernel scheduler memungkinkan UNIX untuk mengatur subsistem file dan proses. Subsistem file bekerja dengan perangkat device raw atau block device. Subsistem Proses mengelola sinkronisasi process, komunikasi antar-proses, manajemen memori dan penjadwalan proses.
+[[Interpreter]] mengelola permintaan system call tingkat pengguna untuk mengakses [[file]] atau proses. [[Kernel scheduler]] memungkinkan [[UNIX]] untuk mengatur subsistem file dan proses. Subsistem file bekerja dengan perangkat device raw atau block device. Subsistem Proses mengelola sinkronisasi process, komunikasi antar-proses, manajemen memori dan penjadwalan proses.
-Kernel mengelola melalui penggunaan dua struktur kunci, tabel proses dan struktur pengguna. Tabel proses berisi parameter penjadwalan, gambar memori, sinyal dan kondisi proses lainnya. Struktur pengguna termasuk registri mesin, kondisi system call , tabel file descriptor, akunting dan stack kernel.
+[[Kernel]] mengelola melalui penggunaan dua struktur penting yaitu, tabel proses dan struktur pengguna. Tabel proses berisi parameter penjadwalan, gambar memori, sinyal dan kondisi proses lainnya. Struktur pengguna termasuk registri mesin, kondisi system call , tabel file descriptor, akunting dan stack kernel.
 ==Tour Linux Kernel Source==

@@ Line 230: / Line 230: @@
 Bahan-bahan ioctl untuk console device berada di vt.c, karena console driver akan mengirimkan ioctl requests ke vt_ioctl().
 Materi tentang ioctl cukup memusingkan kepala. Beberapa request berhubungan dengan device, dan beberapa lagi berhubungan dengan line discipline.
-The 1.1.7x series features the following approach: tty_ioctl.c implements only line discipline requests (namely n_tty_ioctl(), which is the only n_tty function outside of n_tty.c), while the file_operations field points to tty_ioctl() in tty_io.c. If the request number is not resolved by tty_ioctl(), it is passed along to tty->driver.ioctl or, if it fails, to tty->ldisc.ioctl. Driver-related stuff for the console it to be found in vt.c, while line discipline material is in tty_ioctl.c.
+Fitur pada kernel 1.1.7x ke atas: tty_ioctl.c mengimplementasikan line discipline request (dengan nama n_tty_ioctl(), yang merupakan fungsi n_tty satu-satunya yang berada di luar n_tty.c), sementara file_operations field menunjuk ke tty_ioctl() di tty_io.c. Jika nomor request tidak dapat di tangani oleh tty_ioctl(), dia akan meneruskan ke tty->driver.ioctl atau, jika dia gagal, ke tty->ldisc.ioctl. Berbagai hal yang berkenaan dengan driver untuk console dapat ditemukan di vt.c, sementara material line discipline di tty_ioctl.c.
-Note that in both cases, the TIOCLINUX request is in the device-independent code. This implies that the console selection can be set by ioctlling any tty (set_selection() always operates on the foreground console), and this is a security hole. It is also a good reason to switch to a newer kernel, where the problem is fixed by only allowing the superuser to handle the selection.
+Request TIOCLINUX adalah device-independent code. Artinya, console selection dapat di set oleh ioctl dari tty manapun (set_selection() selalu beroperasi di console foreground), dan ini merupakan salah satu security hole di Linux lama. Maka pada Linux yang baru, hanya superuser yang dapat menangani selection.
 Ada banyak jenis request yang di berikan console device, dan cara terbaik untuk mengetahui-nya adalah melihat isi file vt.c.

@@ Line 233: / Line 233: @@
 [NEW]The information above refer to 1.1.7x. The 1.0 kernel doesn't have the ``driver'' table, and vt_ioctl() is pointed to directly by the file_operations() table.
-Ioctl material is quite confused, indeed. Some requests are related to the device, and some are related to the line discipline. I'll try to summarize things for the 1.0 and the 1.1.7x kernels. Anything happened in between.
+Materi tentang ioctl cukup memusingkan kepala. Beberapa request berhubungan dengan device, dan beberapa lagi berhubungan dengan line discipline.
 The 1.1.7x series features the following approach: tty_ioctl.c implements only line discipline requests (namely n_tty_ioctl(), which is the only n_tty function outside of n_tty.c), while the file_operations field points to tty_ioctl() in tty_io.c. If the request number is not resolved by tty_ioctl(), it is passed along to tty->driver.ioctl or, if it fails, to tty->ldisc.ioctl. Driver-related stuff for the console it to be found in vt.c, while line discipline material is in tty_ioctl.c.

@@ Line 241: / Line 241: @@
 Note that in both cases, the TIOCLINUX request is in the device-independent code. This implies that the console selection can be set by ioctlling any tty (set_selection() always operates on the foreground console), and this is a security hole. It is also a good reason to switch to a newer kernel, where the problem is fixed by only allowing the superuser to handle the selection.
-A variety of requests can be issued to the console device, and the best way to know about them is to browse the source file vt.c.
+Ada banyak jenis request yang di berikan console device, dan cara terbaik untuk mengetahui-nya adalah melihat isi file vt.c.
 ==Referensi==