Difference between revisions of "OS: Linux Kernel"

From OnnoWiki
Jump to navigation Jump to search
 
(77 intermediate revisions by the same user not shown)
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==
 
==Tour Linux Kernel Source==
Line 9: Line 9:
 
Oleh Alessandro Rubini, rubini@pop.systemy.it
 
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.
 
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 30: Line 30:
 
Enkapsulasi kernel dalam gzip file dilakukan oleh Makefile dan utility di directory zBoot. Cukup menarik untuk dilihat.
 
Enkapsulasi kernel dalam gzip file dilakukan oleh Makefile dan utility di directory zBoot. Cukup menarik untuk dilihat.
  
−
[NEW]Kernel release 1.1.75 moved the boot and zBoot directories down to arch/i386/boot. This change is meant to allow true kernel builds for different architectures. Nonetheless, I'll stick to i386-specific information.
+
Kernel release 1.1.75 memindahkan directory boot dan zBoot ke arch/i386/boot. Perubahan ini untuk memungkinkan kernel bagi arsitektur yang berbeda. Pada bagian ini, informasi yang diberikan akan spesifik untuk i386.
  
−
Decompressed code is executed at address 0x1010000 [Maybe I've lost track of physical addresses, here, as I don't know very well gas source code], where all the 32-bit setup is accomplished: IDT, GDT and LDT are loaded, the processor and coprocessor are identified, and paging is setup; eventually, the routine start_kernel is invoked. The source for the above operations is in boot/head.S. It is probably the trickiest code in the whole kernel.
+
Decompressed code di execute pada address address 0x1010000 [kemungkinan sekarang berbeda], yang mana semua setup 32bit dilakukan: IDT, GDT dan LDT di load, processor dan coprocessor di identifikasi, paging dilakukan, akhirnya, routine start_kernel dijalankan. Source dari operasi ini adalah boot/head.S. Bagian ini barangkali merupakan bagian paling tricky dari kernel secara keseluruhan.
  
−
Note that if an error occurs during any of the preceding steps, the computer will lockup. The OS can't deal with errors when it isn't yet fully operative.
+
Perlu dicatat bahwa jika terjadi error pada tahapan di atas, komputer akan lockup. Karena sistem operasi tidak dapat mengatasi error karena sistem operasi belum beroperasi dengan penuh.
  
−
start_kernel() resides in init/main.c, and never returns. Anything from now on is coded in C language, left aside interrupt management and system call enter/leave (well, most of the macros embed assembly code, too).
+
start_kernel() ada di init/main.c, dan tidak pernah return. Selanjutnya semua code menggunakan bahasa C, diluar manajemen interrupt dan system call masuk / keluar (sebetulnya kebanyakan marco juga embed assembly code).
−
Spinning the wheel
 
  
−
After dealing with all the tricky questions, start_kernel() initializes all the parts of the kernel, specifically:
+
===Perputaran Roda Sistem Operasi===
  
−
Sets the memory bounds and calls paging_init().
+
Setelah mengatasi berbagai hal yang tricky, start_kernel() menginisialisasi semua bagian dari kernel, terutama,
−
Initializes the traps, IRQ channels and scheduling.
 
−
Parses the command line.
 
−
If requested to, allocates a profiling buffer.
 
−
Initializes all the device drivers and disk buffering, as well as other minor parts.
 
−
Calibrates the delay loop (computes the ``BogoMips'' number).
 
−
Checks if interrupt 16 works with the coprocessor.
 
  
−
Finally, the kernel is ready to move_to_user_mode(), in order to fork the init process, whose code is in the same source file. Process number 0 then, the so-called idle task, keeps running in an infinite idle loop.
+
* Set batas memory dan call ke paging_init().
 +
* Inisialisasi traip, IRQ kanal dan scheduling.
 +
* Parsing command lnine.
 +
* Jika diminta, alokasi profiling buffer.
 +
* Inisialisasi semua device driver dan disk buffer, juga berbagai bagian kecil lainnya.
 +
* Kalibrasi delay loop (biasanya di hitung sebagai angka ``BogoMips'').
 +
* Cek apakah interrupt 16 bekerja dengan baik dengan coprocessor.  
  
−
The init process tries to execute /etc/init, or /bin/init, or /sbin/init.
+
Akhirnya, kernel siap untuk move_to_user_mode(), untuk mem-fork proses init, yang code-nya berada pada source file yang sama. Process nomor 0 yang juga dikenal sebagai idle task akan terus jalan sebagai infinite idle loop.
  
−
If none of them succeeds, code is provided to execute ``/bin/sh /etc/rc'' and fork a root shell on the first terminal. This code dates back to Linux 0.01, when the OS was made by the kernel alone, and no login process was available.
+
Proses init akan berusaha untuk menjalankan /etc/init, atau /bin/init, atau /sbin/init.
  
−
After exec()ing the init program from one of the standard places (let's assume we have one of them), the kernel has no direct control on the program flow. Its role, from now on is to provide processes with system calls, as well as servicing asynchronous events (such as hardware interrupts). Multitasking has been setup, and it is now init which manages multiuser access by fork()ing system daemons and login processes.
+
Jika tidak ada yang berhasil, code akan menjalankan "/bin/sh /etc/rc" dan fork root shell di terminal pertama. Code ini digunakan sejak Linux 0.01, saat itu sistem operasi hanya berupa kernel saja, dan proses tanpa login tersedia.
  
−
Being the kernel in charge of providing services, the tour will proceed by looking at those services (the ``system calls''), as well as by providing general ideas about the underlying data structures and code organization.
+
Setelah exec() program init dari salah satu lokasi standard (kita asumsikan kita memiliki salah satunya), kernel tidak punya kontrol secara langsung terhadap aliran program. Fungsi kernel, selanjutnya adalah untuk memfasilitasi proses melalui system call, juga memberikan layanan untuk kejadian asinkron (seperti interupsi hardware). Multitasking sudah di setip, dan selanjutnya init akan memanaje akses multiuser melalui fork() system daemon dan proses login.
−
How the kernel sees a process
 
  
−
From the kernel point of view, a process is an entry in the process table. Nothing more.
+
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.
  
−
The process table, then, is one of the most important data structures within the system, together with the memory-management tables and the buffer cache. The individual item in the process table is the task_struct structure, quite a huge one, defined in include/linux/sched.h. Within the task_struct both low-level and high-level information is kept--ranging from the copy of some hardware registers to the inode of the working directory for the process.
+
===Bagaimana Kernel Melihat Proses===
  
−
The process table is both an array and a double-linked list, as well as a tree. The physical implementation is a static array of pointers, whose length is NR_TASKS, a constant defined in include/linux/tasks.h, and each structure resides in a reserved memory page. The list structure is achieved through the pointers next_task and prev_task, while the tree structure is quite complex and will not be described here. You may wish to change NR_TASKS from the default vaue of 128, but be sure to have proper dependency files to force recompilation of all the source files involved.
+
Dari sudut pandang kernel, sebuah proses tidak lebih dari sebuah entry pada tabel proses.
  
−
After booting is over, the kernel is always working on behalf of one of the processes, and the global variable current, a pointer to a task_struct item, is used to record the running one. current is only changed by the scheduler, in kernel/sched.c. When, however, all procecces must be looked at, the macro for_each_task is used. It is conderably faster than a sequential scan of the array, when the system is lightly loaded.
+
Oleh karenanya, tabel process adalah salah satu tabel paling penting dalam struktur data di system, bersama dengan tabel memory-management dan buffer cache. Satu-satunya hal (item) yang di simpan di tabel proses adalah struktur task_struct, lumayan besar sekali, di definisikan di definisikan di include/linux/sched.h. Dalam task_struct baik informasi low-level dan high-level disimpan -- mulai dari copy dari register hardware hingga inode dari directory tempat beroperasinya proses.
  
−
A process is always running in either ``user mode'' or ``kernel mode''. The main body of a user program is executed in user mode and system calls are executed in kernel mode. The stack used by the process in the two execution modes is different--a conventional stack segment is used for user mode, while a fixed-size stack (one page, owned by the process) is used in kernel mode. The kernel stack page is never swapped out, because it must be available whenever a system call is entered.
+
Tabel process dapat berupa array dan double-link list, juga tree. Implementasi fisik dapat berupa static array dari pointer, yang panjangnya adalah NR_TASKS, sebuah konstanta yang di definisikan di include/linux/tasks.h, dan setiap struktur berada di bagian page reserved memory. Struktur list diperoleh melalui pointer next_task dan prev_task, sedangkan struktur tree cukup kompleks dan tidak akan di terangkan disini. Kita mungkin ingin mengubah nilai NR_TASKS dari 128, tapi pastikan untuk memaksa mengcompile semua file dependensi yang tergantung kepadanya.
  
−
System calls, within the kernel, exist as C language functions, their `official' name being prefixed by `sys_'. A system call named, for example, burnout invokes the kernel function sys_burnout().
+
Setelah booting selesai, kernel akan selalu bekerja atas nama dari salah satu proses, dan global variable current, sebuah pointer ke item task_struct, digunakan untuk mencatat proses yang sedang berjalan. current hanya akan diubah oleh scheduler, di kernel/sched.c. Akan tetapi, semua proses harus di lihat, macro for_each_task digunakan. Hal ini jauh lebih cepat daripada scan array secara berurutan, jika system dalam kondisi beban yang ringan.
  
−
[MORE]The system call mechanism is described in chapter 3 of this guide. Looking at for_each_task and SET_LINKS, in include/linux/sched.h can help understanding the list and tree structures in the process table.
+
Sebuah proses harus dijalankan dalam mode ''user mode'' atau ''kernel mode''. Badan utama dari user program akan di execute dalam user mode dan system call akan di execute dalam kernel mode. stack yang digunakan oleh process dalam dua mode exekusi juga berbeda -- stack segmen konvensional digunakan dalam user mode, sedang fixed-size stack (satu page,dimiliki oleh process) digunakan dalam kernel mode. Page kernel stack tidak pernah di swap, karena dia harus tersedia jika sewaktu-waktu system call memanggil.
−
Creating and destroying processes
 
  
−
A unix system creates a process though the fork() system call, and process termination is performed either by exit() or by receiving a signal. The Linux implementation for them resides in kernel/fork.c and kernel/exit.c.
+
System calls, dalam kernel, berupa fungsi dalam bahasa C, nama 'official' biasanya menggunakan prefix `sys_'. Sebuah system call diberi nama, sebagai contoh, untuk burnout akan memanggil fungsi kernel sys_burnout().
  
−
Forking is easy, and fork.c is short and ready understandable. Its main task is filling the data structure for the new process. Relevant steps, apart from filling fields, are:
+
Lihat for_each_task dan SET_LINKS, di include/linux/sched.h akan menolong untuk mengerti struktur list dan tree di tabel proses.
  
−
getting a free page to hold the task_struct
+
===Pembuatan dan Penghancuran proses===
−
finding an empty process slot (find_empty_process())
 
−
getting another free page for the kernel_stack_page
 
−
copying the father's LDT to the child
 
−
duplicating mmap information of the father
 
  
−
sys_fork() also manages file descriptors and inodes.
+
Sebuah sistem unix akan membuat proses melalui system call fork(), dan terminasi proses melalui perintah exit() atau dengan memberikan signal. Implementasi Linux dari kedua perintah tersebut berada di kernel/fork.c dan kernel/exit.c.
  
−
[NEW]The 1.0 kernel offers some vestigial support to threading, and the fork() system call shows some hints to that. Kernel threads is work-in-progress outside the mainstream kernel.
+
Fork relatif mudah, dan fork.c lumayan pendek dan sangat mudah untuk dimengerti. Tugas utamanya adalah mengisi struktur data dari proses baru. Langkah yang dilakukan, selain mengisi kolom, adalah:
  
−
Exiting from a process is trickier, because the parent process must be notified about any child who exits. Moreover, a process can exit by being kill()ed by another process (these are Unix features). The file exit.c is therefore the home of sys_kill() and the vairious flavours of sys_wait(), in addition to sys_exit().
+
* Mengambil page yang free untuk meletakan task_struct
 +
* Mencari slot proses yang kosong (find_empty_process())
 +
* Mengambil page yang free untuk kernel_stack_page
 +
* Copy LDT bapak ke anak
 +
* Duplikasi informasi mmap ke bapak
  
−
The code belonging to exit.c is not described here--it is not that interesting. It deals with a lot of details in order to leave the system in a consistent state. The POSIX standard, then, is quite demanding about signals, and it must be dealt with.
+
sys_fork() juga memanaje deskripsi file dan inode.
−
Executing programs
 
  
−
After fork()ing, two copies of the same program are running. One of them usually exec()s another program. The exec() system call must locate the binary image of the executable file, load and run it. The word `load' doesn't necessarily mean ``copy in memory the binary image'', as Linux supports demand loading.
+
Kernel 1.0 memberikan dukungan vestigial untuk threading, dan fork() system call akan menunjukan beberapa hal untuk itu. Kernel thread adalah work-in-progress diluar kernel utama.
  
−
The Linux implementation of exec() supports different binary formats. This is accomplished through the linux_binfmt structure, which embeds two pointers to functions--one to load the executable and the other to load the library, each binary format representing both the executable and the library. Loading of shared libraries is implemented in the same source file as exec() is, but let's stick to exec() itself.
+
Keluar dari sebuah proses lebih triky, karena proses parent harus diberitahu akan adanya child yang berjalan. Tambah lagi, sebuah proses dapat exit jika di kill() oleh proses lain (hal ini adalah fitur Unix). File exit.c oleh karenanya merupakan tempat dari sys_kill() dan berbagai jenis sys_wait(), selain dari sys_exit().
  
−
The Unix systems provide the programmer with six flavours of the exec() function. All but one of them can be implemented as library functions, and theLinux kernel implements sys_execve() alone. It performs quite a simple task: loading the head of the executable, and trying to execute it. If the first two bytes are ``#!'', then the first line is parsed and an interpreter is invoked, otherwise the registered binary formats are sequentially tried.
+
Code dari exit.c tidak akan diterangkan disini -- karena tidak terlalu menarik. Intinya dia akan menangani dari perintah untuk keluar dari system secara konsisten. Standard POSIX, akan secara detail menerangkan tentang berbagai sinyal yang harus di tangani dalam proses keluar tersebut.
  
−
The native Linux format is supported directly within fs/exec.c, and the relevant functions are load_aout_binary and load_aout_library. As for the binaries, the function loading an ``a.out'' executable ends up either in mmap()ing the disk file, or in calling read_exec(). The former way uses the Linux demand loading mechanism to fault-in program pages when they're accessed, while the latter way is used when memory mapping is not supported by the host filesystem (for example the ``msdos'' filesystem).
+
===Menjalankan Program===
  
−
[NEW]Late 1.1 kernels embed a revised msdos filesystem, which supports mmap(). Moreover, the struct linux_binfmt is a linked list rather than an array, to allow loading a new binary format as a kernel module. Finally, the structure itself has been extended to access format-related core-dump routines.
+
Setelah menjalankan fork(), dua copy dari program yang sama akan jalan. Salah satu diantaranya biasanya akan meng-exec() program yang lain. System call exec() harus menemukan lokasi dari image binary dari file executable, me-load dan men-jalan-kannya. Kata "load" disini boleh tentu berarti "copy binary image ke memory", karena Linux mendukung demand loading.
−
Accessing filesystems
 
  
−
It is well known that the filesystem is the most basic resource in a Unix system, so basic and ubiquitous that it needs a more handy name--I'll stick to the standard practice of calling it simply ``fs''.
+
Implementasi exec() di Linux mendukung beberapa format binary. Hal ini dapat dicapai melalui struktur linux_binfmt, dimana ada dua pointer ke fungsi -- satu untuk load executable dan yang lain untuk load library, setiap format binary me-representasikan executable maupun library. Loading dari shared library di implementasikan di source file yang sama dengan exec(), untuk sekarang kita fokus ke exec() saja.
  
−
I'll assume the reader already knows the basic Unix fs ideas--access permissions, inodes, the superblock, mounting and umounting. Those concepts are well explained by smarter authors than me within the standard Unix literature, so I won't duplicate their efforts and I'll stick to Linux specific issues.
+
Unix system memberikan programmer enam pola dari fungsi exec(). Semua kecuali satu dapat di implementasikan sebagai fungsi library, kernel Linux mengimplementasikan sys_execve() sendiri. Dia menjalankan tugas yang sangat sederhana, yaitu, load head dari executable, dan mencoba meng-execute-nya. Jika dua byte pertama adalah "#!", maka kalimat pertama akan di parsing dan interpreter akan di jalankan, selain itu format binary yang terdaftar akan berusaha di coba dijalankan.
  
−
While the first Unices used to support a single fs type, whose structure was widespread in the whole kernel, today's practice is to use a standardized interface between the kernel and the fs, in order to ease data interchange across architectures. Linux itself provides a standardized layer to pass information between the kernel and each fs module. This interface layer is called VFS, for ``virtual filesystem''.
+
Format Linux asli didukung secara langsung dalam fs/exec.c, dan fungsi yang relevan akan me-load binary aout_dan load library aout. Untuk binary, fungsi loading dari executable "a.out" akan berujung pada mmap() ke file disk, atau call read_exec(). mmap() digunakan oleh Linux jika dibutuhkan mekanisme loading ke page memory program saat di akses, sedangkan read_exec() digunakan jika memory mapping tidak didukung oleh filesystem host (contoh filesystem "msdos")
  
−
Filesystem code is therefore split into two layers: the upper layer is concerned with the management of kernel tables and data structures, while the lower layer is made up of the set of fs-dependent functions, and is invoked through the VFS data structures. All the fs-independent material resides in the fs/*.c files. They address the following issues:
+
Kernel 1.1 memasukan revisi filesystem msdos, yang mendukung mmap(). Di samping itu, struct linux_binfmt menjadi linked list bukan sekedar array, untuk memungkinkan loading format binary baru sebagai kernel modul. Selanjutnya, structure yang ada juga di kembangkan untuk mengakses route core-dump yang berhubungan dengan format.
  
−
Managing the buffer chache (buffer.c);
+
===Akses ke File System===
−
Responding to the fcntl() and ioctl() system calls (fcntl.c and ioctl.c);
 
−
Mapping pipes and fifos on inodes and buffers (fifo.c, pipe.c);
 
−
Managing file- and inode-tables (file_table.c, inode.c);
 
−
Locking and unlocking files and records (locks.c);
 
−
Mapping names to inodes (namei.c, open.c);
 
−
Implementing the tricky select() function (select.c);
 
−
Providing information (stat.c);
 
−
mounting and umounting filesystems (super.c);
 
−
exec()ing executables and dumping cores (exec.c);
 
−
Loading the various binary formats (bin_fmt*.c, as outlined above).
 
  
−
The VFS interface, then, consists of a set of relatively high-level operations which are invoked from the fs-independent code and are actually performed by each filesystem type. The most relevant structures are inode_operations and file_operations, though they're not alone: other structures exist as well. All of them are defined within include/linux/fs.h.
+
Kita semua tahu bahwa filesystem adalah sumber daya paling dasar dalam system Uniux, sangat mendasar dan ubiquitous sehingga membutuhkan nama yang mudah di ingat - untuk memudahkan kita akan menggunakan singkatan sederhana "fs".
  
−
The kernel entry point to the actual file system is the structure file_system_type. An array of file_system_types is embodied within fs/filesystems.c and it is referenced whenever a mount is issued. The function read_super for the relevant fs type is then in charge of filling a struct super_block item, which in turn embeds a struct super_operations and a struct type_sb_info. The former provides pointers to generic fs operations for the current fs-type, the latter embeds specific information for the fs-type.
+
Disini akan di asumsikan bahwa pembaca mengerti dasar fs Unix -- ijin akses, inode, superblock, mount dan umount. Konsep ini banyak di terangkan di literatur Unix lainnya. Kita akan banyak membahas isu spesifik fs di Linux.
  
−
[NEW]The array of filesystem types has been turned in a linked list, to allow loading new fs types as kernel modules. The function (un-)register_filesystem is coded within fs/super.c.
+
Unix awal biasanya mendukung satu tipe fs saja, yang strukturnya tersebar dalam seluruh kernel. Pada hari ini, kita menggunakan interface standard antara kernel dengan fs, agar memudahkan pertukaran data pada berbagai arsitektur. Linux memberikan lapisan standard untuk menyampaikan informasi antara kernel dengan modul fs. Lapisan interface ini biasanya di sebut VFS, untuk "virtual filesystem".
−
Quick Anatomy of a Filesystem Type
 
  
−
The role of a filesystem type is to perform the low-level tasks used to map the relatively high level VFS operations on the physical media (disks, network or whatever). The VFS interface is flexible enough to allow support for both conventional Unix filesystems and exotic situations such as the msdos and umsdos types.
+
Code filesystem oleh karenanya biasanya di pecah menjadi dua lapisan: lapisan atas memfokuskan diri pada manajemen dari tabel kernel dan struktur data, sedangkan lapisan bawah terdiri dari sekumpulan fungsi yang fs-dependent, yang di akses melalui struktur data VFS. Semua bagian yang fs-independent berada di file fs/*.c. Mereka menangani isu berikut ini:
  
−
Each fs-type is made up of the following items, in addition to its own directory:
+
* Manaje buffer chache (buffer.c);
 +
* Respond ke system call fcntl() dan ioctl() (fcntl.c dan ioctl.c);
 +
* Memetakan pipe dan fifo pada inode dan buffer (fifo.c, pipe.c);
 +
* Manaje tabel file and inode (file_table.c, inode.c);
 +
* Lock dan unlock file dan record (locks.c);
 +
* Memetakan name ke inode (namei.c, open.c);
 +
* Implementasi fungsi select() (select.c) yang tricky;
 +
* Memberikan informasi (stat.c);
 +
* mount dan umount filesystem (super.c);
 +
* exec() executable dan dump core (exec.c);
 +
* Load berbagai format binary (bin_fmt*.c, seperti diterangkan diatas).
  
−
An entry in the file_systems[] array (fs/filesystems.c);
+
Interface VFS, terdiri dari sekumpulan operasi high-level yang di kerjakan oleh code fs-independent dan di lakukan oleh setiap tipe filesystem. Struktur yang paling relevan adalah inode_operations dan file_operations, meskipun mereka tidak sendiri karena beberapa struktur lain juga ada. Seluruh struktur di definisikan dalam include/linux/fs.h.
−
The superblock include file (include/linux/type_fs_sb.h);
 
−
The inode include file (include/linux/type_fs_i.h);
 
−
The generic own include file (include/linux/type_fs.h});
 
−
Two #include lines within include/linux/fs.h, as well as the entries in struct super_block and struct inode.  
 
  
−
The own directory for the fs type contains all the real code, responsible of inode and data management.
+
Pintu masuk dalam kernel ke file system yang sebenarnya ada di struktur file_system_type. Array file_system_types terdapat dalam fs/filesystems.c dan digunakan saat perintah mount diberikan. Fungsi read_super dari tipe fs yang relevan akan bertanggung jawab untuk mengisi struct super_block, yang akhirnya juga mengisi struct super_operations dan struct type_sb_info. struct super_operations memberikan pointer untuk operasi fs yang generik untuk fs-type current, struct type_sb_info memberikan informasi yang lebih spesifik tentang fs-type.
  
−
[MORE]The chapter about procfs in this guide uncovers all the details about low-level code and VFS interface for that fs type. Source code in fs/procfs is quite understandable after reading the chapter.
+
Array tipe filesystem sudah menjadi linked list, untuk membuka kemungkinan load tipe fs baru sebagai kernel module. Fungsi (un-)register_filesystem di masukan dalam fs/super.c.
  
−
We'll now look at the internal workings of the VFS mechanism, and the minix filesystem source is used as a working example. I chose the minix type because it is small but complete; moreover, any other fs type in Linux derives from the minix one. The ext2 type, the de-facto standard in recent Linux installations, is much more complex than that and its exploration is left as an exercise for the smart reader.
+
===Anatomi dari Tipe File System===
  
−
When a minix-fs is mounted, minix_read_super fills the super_block structure with data read from the mounted device. The s_op field of the structure will then hold a pointer to minix_sops, which is used by the generic filesystem code to dispatch superblock operations.
+
Tugas dari filesystem type adalah untuk menjalankan tugas low-level yang di petakan ke operasi VFS yang lebih high level pada media fisik (disk, networ atau apa saja). Interface VFS cukup flexibel untuk mendukung filesystem Unix konvensional maupun yang tidak konvensional seperti msdos dan umsdos.
  
−
Chaining the newly mounted fs in the global system tree relies on the following data items (assuming sb is the super_block structure and dir_i points to the inode for the mount point):
+
Setiap fs-type dibangun oleh hal berikut, di samping directory sendiri:
  
−
  sb->s_mounted points to the root-dir inode of the mounted filesystem (MINIX_ROOT_INO);
+
* Entry ke array file_systems[] (fs/filesystems.c);
−
dir_i->i_mount holds sb->s_mounted;
+
* include file superblock (include/linux/type_fs_sb.h);
−
sb->s_covered holds dir_i
+
* include file inode (include/linux/type_fs_i.h);
 +
* include file generic (include/linux/type_fs.h});
 +
* Dua #include dalam include/linux/fs.h, termasuk entry struct super_block dan struct inode.
  
−
Umounting will eventually be performed by do_umount, which in turn invokes minix_put_super.
+
Directory yang dimiliki oleh fs type berisi semua code, yang bertanggung jawab terhadap inode dan data management.
  
−
Whenever a file is accessed, minix_read_inode comes into play; it fills the system-wide inode structure with fields coming form minix_inode. The inode->i_op field is filled according to inode->i_mode and it is responsible for any further operation on the file. The source for the minix functions just described are to be found in fs/minix/inode.c.
+
Untuk melihat dari dekat bagaimana low-level code dan interface VFS bekerja untuk fs type ada baiknya memnaca procfs. Source code fs/procfs cukup mudah dibaca.
  
−
The inode_operations structure is used to dispatch inode operations (you guessed it) to the fs-type specific kernel functions; the first entry in the structure is a pointer to a file_operations item, which is the data-management equivalent of i_op. The minix fs-type allows three instances of inode-operation sets (for direcotries, for files and for symbolic links) and two instances of file-operation sets (symlinks don't need one).
+
Selanjutnya kita akan mencoba melihat mekanisme kerja di dalam VFS, minix filesystem akan digunakan sebagai contoh. minix type dipilih karena relatif kecil tapi cukup komplit; di samping itu, fs type linux lainnya diturunkan dari minix. ext2 type jauh lebih komplex mungkin bisa menjadi pelajaran bagi pembaca yang cukup tekun.
  
−
Directory operations (minix_readdir alone) are to be found in fs/minix/dir.c; file operations (read and write) appear within fs/minix/file.c and symlink operations (reading and following the link) in fs/minix/symlink.c.
+
Pada saat minix-fs di mount, minix_akan membaca read_super dan mengisi struktur super_block dengan data yang dibaca dari device yang di mount. Parameter s_op dalam struktur tersebut akan menyimpan pointer ke minix_sops, yang digunakan oleh code filesystem generik yang dijalankan oleh operasi superblock.
  
−
The rest of the minix directory implements the following tasks:
+
Mengkaitkan fs yang baru saja di mount ke sistem tree global bergantung pada data berikut (asumsinya sb adalah struktur super_block dan dir_i point ke inode untuk mount point):
  
−
  bitmap.c manages allocation and freeing of inodes and blocks (the ext2 fs, otherwise, has two different source files);
+
  sb->s_mounted point ke root-dir inode dari mounted filesystem (MINIX_ROOT_INO);
−
  fsynk.c is responsible for the fsync() system calls--it manages direct, indirect and double indirect blocks (I assume you know about them, it's common Unix knowledge);
+
  dir_i->i_mount menyimpan sb->s_mounted;
−
  namei.c embeds all the name-related inode operations, such as creating and destroying nodes, renaming and linking;
+
  sb->s_covered menyimpan dir_i
−
truncate.c performs truncation of files.
 
  
−
===The console driver===
+
Umount dapat dilakukan oleh do_umount, yang akan menjalankan minix_put_super.
  
−
Being the main I/O device on most Linux boxes, the console driver deserves some attention. The source code related to the console, as well as the other character drivers, is to be found in drivers/char, and we'll use this very directory as our referenece point when naming files.
+
Jika sebuah file di akses, minix_read_inode akan mulai bekerja; dia akan mengisi system-wide struktur inode dengan field dari minix_inode. Field inode->i_op akan di isi sesuai dengan inode->i_mode dan dia akan bertanggung jawab akan operasi selanjutnya pada file tersebut. Source untuk fungsi minix yang baru saja dijelasnkan dapat dilihat di fs/minix/inode.c.
  
−
Console initialization is performed by the function tty_init(), in tty_io.c. This function is only concerned in getting major device numbers and calling the init function for each device set. con_init(), then is the one related to the console, and resides in console.c.
+
Struktur inode_operations digunakan untuk menjalankan operasi inode ke fungsi kernel yang spesifik fs-type; entry pertama di struktur adalah pointer ke item file_operations, yang equivalen dengan data-management dari i_op. minix fs-type mengijinkan tiga instance dari inode-operation (untuk directori, untuk file dan untuk symbolic link) dan dua instance dari file-operation (symlinks tidak memerlukan hal ini).
  
−
[NEW]Initialization of the console has changed quite a lot during 1.1 evolution. console_init() has been detatched from tty_init(), and is called directly by ../../main.c. The virtual consoles are now dynamically allocated, and quite a good deal of code has changed. So, I'll skip the details of initialization, allocation and such.
+
Operasi directori (minix_readdir) dapat ditemukan di fs/minix/dir.c; operasi file (read dan write) ada di fs/minix/file.c dan operasi symlink (reading dan following link) ada di fs/minix/symlink.c.
−
How file operations are dispatched to the console
 
  
−
This paragraph is quite low-level, and can be happily skipped over.
+
Selebihnya dari minix directory mengimplementasikan tugas berikut:
  
−
Needless to say, a Unix device is accessed though the filesystem. This paragraph details all steps from the device file to the actual console functions. Moreover, the following information is extracted from the 1.1.73 source code, and it may be slightly different from the 1.0 source.
+
* bitmap.c mengatur alokasi dan pembebasan inode dan block (pada ext2 fs, hal ini dilakukan pada dua source file yang berbeda);
 +
* fsynk.c bertanggung jawab untuk system call fsync() -- dia mengatur block direct, indirect dan double indirect (ini merupakan bagian dari pengetahuan umum Unix);
 +
* namei.c berisi semua operasi nama pada inode, seperti membuat dan memhancurkan node, rename dan links;
 +
* truncate.c menjalankan pemotongan (truncatin) dari file.
  
−
When a device inode is opened, the function chrdev_open() (or blkdev_open(), but we'll stich to character devices) in ../../fs/devices.c gets executed. This function is reached by means of the structure def_chr_fops, which in turn is referenced by chrdev_inode_operations, used by all the filesystem types (see the previous section about filesystems).
+
===console driver===
  
−
chrdev_open takes care of specifying the device operations by substituting the device specific file_operations table in the current filp and calls the specific open(). Device specific tables are kept in the array chrdevs[], indexed by the majour device number, and filled by the same ../../fs/devices.c.
+
Karena merupakan I/O device utama di sebagian besar Linux, console driver perlu memperoleh perhatian lebih. Source code dari console, maupun berbagai karakter driver, dapat ditemukan pada drivers/char, dan kita akan menggunakan directory tersebut sebagai titik referensi ketika melakukan penamaan file.
  
−
If the device is a tty one (aren't we aiming at the console?), we come to the tty drivers, whose functions are in tty_io.c, indexed by tty_fops. Thus, tty_open() calls init_dev(), which allocates any data structure needed by the device, based on the minor device number.
+
Inisialisasi Console dilakukan oleh fungsi tty_init(), di tty_io.c. Fungsi bertanggung jawab untuk memperoleh nomor device dan memanggil fungsi init untuk masing-masing device. con_init(), yang kemudian menghubungkan ke console, dan berada console.c.
  
−
The minor number is also used to retrieve the actual driver for the device, which has been registered through tty_register_driver(). The driver, then, is still another structure used to dispatch computation, just like file_ops; it is concerned with writing and controlling the device. The last data structure used in managing a tty is the line discipline, described later. The line discipline for the console (and any other tty device) is set by initialize_tty_struct(), invoked by init_dev.
+
Inisialisasi console telah berubah lumayan banyak pada evolusi 1.1. console_init() dilepas dari tty_init(), dan dapat di panggil secara langsung oleh ../../main.c. Virtual console dialokasikan secara dinamis.
  
−
Everything we touched in this paragraph is device-independent. The only console-specific particular is that console.c, has registered its own driver during con_init(). The line discipline, on the contrary, in independent of the device.
+
===Write ke console===
  
−
[MORE]The tty_driver structure is fully explained within <linux/tty_driver.h>.
+
Jika console device di tulis, fungsi con_write akan di jalankan. Fungsi ini mengatur semua control karakter dan escape sequences yang digunakan oleh aplikasi untuk memperoleh manajemen layar (screen) secara lengkap. escape sequence yang di implementasikan adalah milik terminal vt102; Hal ini berarti bahwa environment kita perlu di set TERM=vt102 jika kita melakukan telnet ke host non-Linux; untuk aktifitas lokal, lebih baik menggunakan TERM=console karena console Linux memberikan fungsi superset dari vt102.
  
−
[NEW]The above information has been extracted from 1.1.73 source code. It isn't unlikely for your kernel to be somewhat different (``This information is subject to change without notice'').
+
con_write(), sebagian besar merupakan pernyataan nested switch, yang digunakan untuk meng-handel finite state automaton yang meng-interpretasikan escape sequences karakter satu per satu. Saat mode normal, character yang di cetak akan di tulis secara langsung ke memory video, menggunakan current attr-ibute. Dalam console.c, semua field struct vc dapat di akses melalui macro, oleh karenanya referensi ke (contoh) attr, sebetulnya me-refer ke field di struktur vc_cons[currcons], selama currcons adalah nomor dari console yang di referensikan.
  
−
===Writing to the console===
+
Sebetulnya, vc_cons di kernel yang baru, tidak lagi berupa array dari struktur, dia berupa array dari pointer yang isinya di kmalloc() -kan. Penggunaan macro sangat menyederhanakan perubahan yang dilakukan, karena sebagian besar code tidak perlu di tulis ulang.
  
−
When a console device is written to, the function con_write gets invoked. This function manages all the control characters and escape sequences used to provide applications with complete screen management. The escape sequences implemented are those of the vt102 terminal; This means that your environment should say TERM=vt102 when you are telnetting to a non-Linux host; the best choice for local activities, however, is TERM=console because the Linux console offers a superset of vt102 functionality.
+
mapping dan unmapping dari console memory ke screen dilakukan oleh fungsi set_scrmem() (yang mengcopy data dari buffer console ke video memory) dan get_scrmem (yang mengcopydata kembali ke buffer console). buffer private dari current console secara fisik di map ke video RAM, untuk meminimalkan jumlah data yang perlu di transfer. Hal ini berarti, get- dan set-_scrmem() secara statik ada di console.c dan di panggil hanya saat console switch.
  
−
con_write(), thus, is mostly made up of nested switch statements, used to handle a finite state automaton interpreting escape sequences one character at a time. When in normal mode, the character being printed is written directly to the video memory, using the current attr-ibute. Within console.c, all the fields of struct vc are made accessible through macros, so any reference to (for example) attr, does actually refer to the field in the structure vc_cons[currcons], as long as currcons is the number of the console being referred to.
+
===Read console===
  
−
[NEW]Actually, vc_cons in newer kernels is no longer an array of structures , it now is an array of pointers whose contents are kmalloc()ed. The use of macros greatly simplified changing the approach, because much of the code didn't need to be rewritten.
+
Membaca (read) console dilakukan melalui line-discipline. default (dan unique) line discipline di Linux di kenal sebagai tty_ldisc_N_TTY. line discipline adalah "men-displin input melalui line". Ini merupakan tabel fungsi, yang fokus untuk membaca device. Dengan di bantu oleh flag termios, line discipline mengontrol input dari tty: raw, cbreak dan cooked mode; select(); ioctl() dan sebagainya.
  
−
Actual mapping and unmapping of the console memory to screen is performed by the functions set_scrmem() (which copies data from the console buffer to video memory) and get_scrmem (which copies back data to the console buffer). The private buffer of the current console is physically mapped on the actual video RAM, in order to minimize the number of data transfers. This means that get- and set-_scrmem() are static to console.c and are called only during a console switch.
+
Fungsi read di line discipline di sebut read_chan(), yang akan membaca which tty buffer secara independent dari masukan yang ada. Alasannya, karena masuknya karakter melalui tty di tangani oleh interupsi hardware secara asinkron.
−
Reading the console
 
  
−
Reading the console is accomplished through the line-discipline. The default (and unique) line discipline in Linux is called tty_ldisc_N_TTY. The line discipline is what ``disciplines input through a line''. It is another function table (we're used to the approach, aren't we?), which is concerned with reading the device. With the help of termios flags, the line discipline is what controls input from the tty: raw, cbreak and cooked mode; select(); ioctl() and so on.
+
Line discipline N_TTY dapat ditemukan di tty_io.c, kernel selanjutnya akan menggunakan source file n_tty.c yang berbeda.
  
−
The read function in the line discipline is called read_chan(), which reads the tty buffer independently of whence it came from. The reason is that character arrival through a tty is managed by asynchronous hardware interrupts.
+
Bagian paling bawah dari console input adalah bagian dari manajemen  keyboard, dan oleh karenanya akan di tangani dalam keyboard.c, dalam fungsi keyboard_interrupt().
  
−
[MORE]The line discipline N_TTY is to be found in the same tty_io.c, though later kernels use a different n_tty.c source file.
+
===Manajemen Keyboard===
  
−
The lowest level of console input is part of keyboard management, and thus it is handled within keyboard.c, in the function keyboard_interrupt().
+
Majamen Keyboard cukup membuat kepala pusing. Oleh karenanya dia dibatasi di file keyboard.c, yang berisi banyak angka hexadecimal yang merepresentasikan banyak kode keyboard yang muncul di keyboard dari berbagai pembuat keyboard.
−
Keyboard management
 
  
−
Keyboard management is quite a nightmare. It is confined to the file keyboard.c, which is full of hexadecimal numbers to represent the various keycodes appearing in keyboards of different manifacturers.
+
Bagi pembaca yang sangat tertarik dengan Linux keyboard, cara terbaik untuk membaca keyboard.c adalah mulai dari kalimat terakhir ke atas. Detail pada tingkat yang paling rendah terutama pada setengah pertama dari file tersebut.
  
−
I won't dig in keyboard.c, because no relevant information is there to the kernel hacker.
+
===Switching current console===
  
−
[MORE]For those readers who are really interested in the Linux keyboard, the best approach to keyboard.c is from the last line upward. Lowest level details occur mainly in the first half of the file.
+
current console di switch dengan cara mengaktifkan fungsi change_console(), yang berada di tty_io.c dan di aktifkan oleh keyboard.c dan vt.c (sebelumnya console switch untuk meresponds tombol keyboard yang di tekan, belakangan jika program me-request dengan cara memanggil ioctl()).
−
Switching the current console
 
  
−
The current console is switched through invocation of the function change_console(), which resides in tty_io.c and is invoked by both keyboard.c and vt.c (the former switches console in response to keypresses, the latter when a program requests it by invoking an ioctl() call).
+
Proses switch yang sebenarnya dilakukan dalam dua langkah, dan fungsi complete_change_console() yang menangani langkah ke dua. Membagi switch berarti untuk menyelesaikan sebuah tugas sesudah terjadi handshake dengan proses yang mengontrol tty sesudah kita tinggalkan. Jika console tidak di bawah kontrol proses, call ke change_console() akan di selesaikan oleh complete_change_console() sendiri. Intervensi proses diperlukan untuk bisa melakukan switch secara baik antara console grafik dengan text dan sebaliknya, dan pada server X (sebagai contoh) dia akan mengontrol sendiri console grafik-nya.
  
−
The actual switching process is performed in two steps, and the function complete_change_console() takes care of the second part of it. Splitting the switch is meant to complete the task after a possible handshake with the process controlling the tty we're leaving. If the console is not under process control, change_console() calls complete_change_console() by itself. Process intervertion is needed to successfully switch from a graphic console to a text one and viceversa, and the X server (for example) is the controlling process of its own graphic console.
+
===Mekanisme seleksi (selection)===
−
The selection mechanism
 
  
−
``selection'' is the cut and paste facility for the Linux text consoles. The mechanism is mainly handled by a user-level process, which can be instantiated by either selection or gpm. The user-level program uses ioctl() on the console to tell the kernel to highlight a region of the screen. The selected text, then, is copied to a selection buffer. The buffer is a static entity in console.c. Pasting text is accomplished by `manually' pushing characters in the tty input queue. The whole selection mechanism is protected by #ifdef so users can disable it during kernel configuration to save a few kilobytes of ram.
+
"selection" adalah fasilitas  cut and paste untuk text console di Linux. Mekanisme ini biasanya di tangani oleh proses pada user-level, yang biasanya di inisiasi oleh selection atau gpm. Program pada user-level menggunakan ioctl() pada console untuk memberitahukan pada kernel untuk meng-highlight bagian pada layar. Text yang di select, kemudian akan di copy ke selection buffer. buffer ini merupakan entitas statik di console.c. Paste text dilakukan secara "manual" mem-push karakter di antrian tty input. Seluruh mekanisme selection di proteksi oleh #ifdef sehingga user dapat men-disable-nya saat konfigurasi kernel untuk menghemat beberapa kilobyte dari RAM.
  
−
Selection is a very-low-level facility, and its workings are hidden from any other kernel activity. This means that most #ifdef's simply deals with removing the highlight before the screen is modified in any way.
+
Selection adalah fasilitas yang sangat low-level, dan dia bekerja secara tersembunyi dari aktifitas kernel lainnya. Hal ini berarti #ifdef hanya menghilangkan highlight sebelum screen di modifikasi.
  
−
[NEW]Newer kernels feature improved code for selection, and the mouse pointer can be highlighted independently of the selected text (1.1.32 and later). Moreover, from 1.1.73 onward a dynamic buffer is used for selected text rather than a static one, making the kernel 4kB smaller.
+
Kernel yang baru mempunyai code yang lebih baik untuk selection, dan pointer mouse dapat di highlight secara independent oleh text yang di select. Selanjutnya, sejak versi 1.1.73 dan seterusnya digunakan dynamic buffer untuk text yang dipilih, membuat kernel 4kB lebih kecil.
−
ioctl()ling the device
 
  
−
The ioctl() system call is the entry point for user processes to control the behaviour of device files. Ioctl management is spawned by ../../fs/ioctl.c, where the real sys_ioctl() resides. The standard ioctl requests are performed right there, other file-related requests are processed by file_ioctl() (same source file), while any other request is dispatches to the device-specific ioctl() function.
+
===ioctl() dari device===
  
−
The ioctl material for console devices resides in vt.c, because the console driver dispatches ioctl requests to vt_ioctl().
+
System call ioctl() merupakan pintu masuk untuk proses user untuk mengontrol perilaku sebuah file device. Manajemen ioctl di-spawn oleh ../../fs/ioctl.c, dimana sys_ioctl() yang sebenarnya berada. Permohonan standard ioctl akan ditangani di situ, permohonan yang berhubungan dengan file akan di proses oleh file_ioctl() (di source file yang sama), sedangkan proses lainnya akan di proses oleh fungsi ioctl() yang spesifik untuk device tersebut.
  
−
[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.
+
Bahan-bahan ioctl untuk console device berada di vt.c, karena console driver akan mengirimkan ioctl requests ke vt_ioctl().
  
−
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.
+
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.
  
−
In the 1.0 kernel, tty_ioctl() is in tty_ioctl.c and is pointed to by generic tty file_operations. Unresolved requests are passed along to the specific ioctl function or to the line-discipline code, in a way similar to 1.1.7x.
+
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.
  
−
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.
+
Ada banyak jenis request yang di berikan console device, dan cara terbaik untuk mengetahui-nya adalah melihat isi file vt.c.
−
 
 
−
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.
 
  
 
==Referensi==
 
==Referensi==
Line 261: Line 247:
 
* [[Linux]]
 
* [[Linux]]
 
* [[Ubuntu]]
 
* [[Ubuntu]]
 +
* [[Buku Sistem Operasi]]
 +
 +
===Secara Umum===
 +
 
* [[Sistem Operasi]]
 
* [[Sistem Operasi]]
 +
 +
===Instalasi Linux===
 +
 +
* [[Linux: CLI untuk Survival]]
 +
* [[Linux: Skema Partisi di Linux]]
 +
* [[Linux: Instalasi Sistem Operasi]]
 +
 +
===Compile Kernel===
 +
 +
* [[Kernel]]
 
* [[OS: Linux Kernel]]
 
* [[OS: Linux Kernel]]
 +
* [[Kernel: Anatomi Kernel Source]]
 +
* [[Compile Kernel]]
 +
* [[Compile Kernel: Konfigurasi Kernel]]
 +
 +
===Remaster Linux===
 +
 +
* [[Cara Cepat Melakukan Remastering Ubuntu]]
 +
 +
===Sistem Operasi untuk Embedded===
 +
 +
* [[OpenWRT]]
 +
* [[OpenWRT: Download Firmware yang sudah jadi]]
 +
* [[OpenWRT: Source Repository Download]]
 +
* [[OpenWRT: Melihat Daftar Package]]
 +
 +
====Membuat Firmware Sendiri====
 +
 +
* [[OpenWRT: Build Firmware]]
 +
* [[OpenWRT: Build Firmware Buffalo WZRHPG450H]]
 +
* [[OpenWRT: Build Firmware Buffalo WZRHPG300N]]
 +
* [[OpenWRT: Build Firmware Ubiquiti NanoStation2]]
 +
* [[OpenWRT: Build Firmware Mikrotik RB433]]
 +
* [[OpenWRT: Build Firmware Linksys WRT160NL]]
 +
* [[OpenWRT: Build Firmware Linksys WRT54GL]]
 +
 +
====Flash ke Device====
 +
 +
* [[OpenWRT: Flash Linksys WRT54GL]]
 +
* [[OpenWRT: Flash Buffalo WZRHP450H]]
 +
* [[OpenWRT: Flash Buffalo WZRHP300N]]
 +
* [[OpenWRT: Flash UBNT NanoStation2]]
 +
 +
====Beberapa Tip====
 +
 +
* [[OpenWRT: Mikrotik RB433]]
 +
* [[OpenWRT: 3G modem]]
 +
* [[OpenWRT: Build Firmware dengan 3G Modem Support]]
 +
* [[OpenWRT: Setup Firewall]]
 +
* [[OpenWRT: Konfigurasi UBNT NanoStation2 tanpa WebGUI]]
 +
 +
===Tuning Kernel===
 +
 
* [[OS: Parameter Kernel Default]]
 
* [[OS: Parameter Kernel Default]]
 +
 +
====Tuning Kernel Scheduler====
 +
 
* [[OS: Kernel Scheduler]]
 
* [[OS: Kernel Scheduler]]
 +
* [[OS: Tuning Kernel Scheduler]]
 +
* [[OS: Tuning Completely Fair scheduler CFS]]
 
* [[OS: Complete Teori Tuning Kernel Scheduler]]
 
* [[OS: Complete Teori Tuning Kernel Scheduler]]
−
* [[OS: Tuning Kernel Scheduler]]
+
 
 +
====Tuning I/O Scheduler====
 +
 
 
* [[OS: Tuning Completely Fair Queueing CFQ I/O scheduler]]
 
* [[OS: Tuning Completely Fair Queueing CFQ I/O scheduler]]
−
* [[OS: Tuning Completely Fair scheduler CFS]]
+
* [[OS: Complete Teori Tuning I/O Performance]]
 +
 
 +
====Tuning Manajemen Memory====
 +
 
 +
* [[OS: Tuning Manajemen Memory]]
 +
 
 +
===Android===
 +
 
 +
* [[OS: Android - Download]]
 +
 
 +
===Membuat Kernel Module===
 +
 
 +
* [[OS: Mengerti System Call]]
 +
* [[OS: Membuat Kernel Modul]]
 +
 
 +
===Monitoring & Benchmark===
 +
 
 
* [[OS: Build in Monitoring Tool]]
 
* [[OS: Build in Monitoring Tool]]
 
* [[Linux Benchmarking]]
 
* [[Linux Benchmarking]]
 
* [[OS: Benchmarking menggunakan UnixBench]]
 
* [[OS: Benchmarking menggunakan UnixBench]]
 
* [[OS: Benchmarking menggunakan LLCBench]]
 
* [[OS: Benchmarking menggunakan LLCBench]]

Latest revision as of 15:12, 15 May 2013

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.

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

Sumber: http://www.tldp.org/LDP/khg/HyperNews/get/tour/tour.html 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.

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.

Setiap pathname untuk file direferensikan dalam bagian ini mengacu pada direktori utama, biasanya 

/usr/src/linux


Booting System

Saat PC di nyalakan, processor 80x86 akan beroperasi menggunakan mode real dan menjalankan code di address 0xFFFF0, yang merupakan address ROM-BIOS. PC BIOS menjalankan beberapa test pada sistem dan menginisialisasi vector interupsi pada address fisik 0. Setelah itu, PC akan memasukan sektor pertama dari bootable device ke 0x7C00, dan jump ke situ. Device tersebut biasanya floppy atau hard drive. Memang ini terlihat sederhana, tapi memang hanya itu yang dibutuhkan untuk mengerti bagaimana awal kernel beroperasi.

Bagian pertama dari Linux kernel di tulis dalam bahasa assembler 8086 (boot/bootsect.S). Jika dijalankan, dia akan pindah ke address absolut di 0x90000, load 2 kBytes dari code selanjutnya dari boot device ke address 0x90200, dan seluruh sisa kernel ke address 0x10000. Message "Loading..." akan ditampilkan saat sistem load. Kontrol diberikan kepada code boot/Setup.S, real-mode assembly source yang lain.

Bagian dari setup mengidentifikasi fitur dari mesin dan tipe dari VGA. Jika di minta, dia juga akan menanyakan kepada pengguna untuk memilih mode video untuk console. Selanjutnya, dia akan memindahkan seluruh sistem dari address 0x10000 ke address 0x1000, masuk ke mode protected dan jump ke sistem yang ada 0x1000.

Langkah selanjutnya adalah proses dekompresi kernel. Code berada pada 0x1000 berasal dari zBoot/head.S yang akan menginisialisasi register dan menjalankan decompress_kernel(), yang akan membuat zBoot/inflate.c, zBoot/unzip.c dan zBoot/misc.c. Data yang sudah di-dekompres masuk ke address 0x100000 (1 Meg), dan hal ini yang menyebabkan Linux biasanya tidak dapat di jalankan di RAM kurang dari 2MB.

Enkapsulasi kernel dalam gzip file dilakukan oleh Makefile dan utility di directory zBoot. Cukup menarik untuk dilihat.

Kernel release 1.1.75 memindahkan directory boot dan zBoot ke arch/i386/boot. Perubahan ini untuk memungkinkan kernel bagi arsitektur yang berbeda. Pada bagian ini, informasi yang diberikan akan spesifik untuk i386.

Decompressed code di execute pada address address 0x1010000 [kemungkinan sekarang berbeda], yang mana semua setup 32bit dilakukan: IDT, GDT dan LDT di load, processor dan coprocessor di identifikasi, paging dilakukan, akhirnya, routine start_kernel dijalankan. Source dari operasi ini adalah boot/head.S. Bagian ini barangkali merupakan bagian paling tricky dari kernel secara keseluruhan.

Perlu dicatat bahwa jika terjadi error pada tahapan di atas, komputer akan lockup. Karena sistem operasi tidak dapat mengatasi error karena sistem operasi belum beroperasi dengan penuh.

start_kernel() ada di init/main.c, dan tidak pernah return. Selanjutnya semua code menggunakan bahasa C, diluar manajemen interrupt dan system call masuk / keluar (sebetulnya kebanyakan marco juga embed assembly code).

Perputaran Roda Sistem Operasi

Setelah mengatasi berbagai hal yang tricky, start_kernel() menginisialisasi semua bagian dari kernel, terutama,

  • Set batas memory dan call ke paging_init().
  • Inisialisasi traip, IRQ kanal dan scheduling.
  • Parsing command lnine.
  • Jika diminta, alokasi profiling buffer.
  • Inisialisasi semua device driver dan disk buffer, juga berbagai bagian kecil lainnya.
  • Kalibrasi delay loop (biasanya di hitung sebagai angka ``BogoMips).
  • Cek apakah interrupt 16 bekerja dengan baik dengan coprocessor.

Akhirnya, kernel siap untuk move_to_user_mode(), untuk mem-fork proses init, yang code-nya berada pada source file yang sama. Process nomor 0 yang juga dikenal sebagai idle task akan terus jalan sebagai infinite idle loop.

Proses init akan berusaha untuk menjalankan /etc/init, atau /bin/init, atau /sbin/init.

Jika tidak ada yang berhasil, code akan menjalankan "/bin/sh /etc/rc" dan fork root shell di terminal pertama. Code ini digunakan sejak Linux 0.01, saat itu sistem operasi hanya berupa kernel saja, dan proses tanpa login tersedia.

Setelah exec() program init dari salah satu lokasi standard (kita asumsikan kita memiliki salah satunya), kernel tidak punya kontrol secara langsung terhadap aliran program. Fungsi kernel, selanjutnya adalah untuk memfasilitasi proses melalui system call, juga memberikan layanan untuk kejadian asinkron (seperti interupsi hardware). Multitasking sudah di setip, dan selanjutnya init akan memanaje akses multiuser melalui fork() system daemon dan proses login.

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 Melihat Proses

Dari sudut pandang kernel, sebuah proses tidak lebih dari sebuah entry pada tabel proses.

Oleh karenanya, tabel process adalah salah satu tabel paling penting dalam struktur data di system, bersama dengan tabel memory-management dan buffer cache. Satu-satunya hal (item) yang di simpan di tabel proses adalah struktur task_struct, lumayan besar sekali, di definisikan di definisikan di include/linux/sched.h. Dalam task_struct baik informasi low-level dan high-level disimpan -- mulai dari copy dari register hardware hingga inode dari directory tempat beroperasinya proses.

Tabel process dapat berupa array dan double-link list, juga tree. Implementasi fisik dapat berupa static array dari pointer, yang panjangnya adalah NR_TASKS, sebuah konstanta yang di definisikan di include/linux/tasks.h, dan setiap struktur berada di bagian page reserved memory. Struktur list diperoleh melalui pointer next_task dan prev_task, sedangkan struktur tree cukup kompleks dan tidak akan di terangkan disini. Kita mungkin ingin mengubah nilai NR_TASKS dari 128, tapi pastikan untuk memaksa mengcompile semua file dependensi yang tergantung kepadanya.

Setelah booting selesai, kernel akan selalu bekerja atas nama dari salah satu proses, dan global variable current, sebuah pointer ke item task_struct, digunakan untuk mencatat proses yang sedang berjalan. current hanya akan diubah oleh scheduler, di kernel/sched.c. Akan tetapi, semua proses harus di lihat, macro for_each_task digunakan. Hal ini jauh lebih cepat daripada scan array secara berurutan, jika system dalam kondisi beban yang ringan.

Sebuah proses harus dijalankan dalam mode user mode atau kernel mode. Badan utama dari user program akan di execute dalam user mode dan system call akan di execute dalam kernel mode. stack yang digunakan oleh process dalam dua mode exekusi juga berbeda -- stack segmen konvensional digunakan dalam user mode, sedang fixed-size stack (satu page,dimiliki oleh process) digunakan dalam kernel mode. Page kernel stack tidak pernah di swap, karena dia harus tersedia jika sewaktu-waktu system call memanggil.

System calls, dalam kernel, berupa fungsi dalam bahasa C, nama 'official' biasanya menggunakan prefix `sys_'. Sebuah system call diberi nama, sebagai contoh, untuk burnout akan memanggil fungsi kernel sys_burnout().

Lihat for_each_task dan SET_LINKS, di include/linux/sched.h akan menolong untuk mengerti struktur list dan tree di tabel proses.

Pembuatan dan Penghancuran proses

Sebuah sistem unix akan membuat proses melalui system call fork(), dan terminasi proses melalui perintah exit() atau dengan memberikan signal. Implementasi Linux dari kedua perintah tersebut berada di kernel/fork.c dan kernel/exit.c.

Fork relatif mudah, dan fork.c lumayan pendek dan sangat mudah untuk dimengerti. Tugas utamanya adalah mengisi struktur data dari proses baru. Langkah yang dilakukan, selain mengisi kolom, adalah:

  • Mengambil page yang free untuk meletakan task_struct
  • Mencari slot proses yang kosong (find_empty_process())
  • Mengambil page yang free untuk kernel_stack_page
  • Copy LDT bapak ke anak
  • Duplikasi informasi mmap ke bapak

sys_fork() juga memanaje deskripsi file dan inode.

Kernel 1.0 memberikan dukungan vestigial untuk threading, dan fork() system call akan menunjukan beberapa hal untuk itu. Kernel thread adalah work-in-progress diluar kernel utama.

Keluar dari sebuah proses lebih triky, karena proses parent harus diberitahu akan adanya child yang berjalan. Tambah lagi, sebuah proses dapat exit jika di kill() oleh proses lain (hal ini adalah fitur Unix). File exit.c oleh karenanya merupakan tempat dari sys_kill() dan berbagai jenis sys_wait(), selain dari sys_exit().

Code dari exit.c tidak akan diterangkan disini -- karena tidak terlalu menarik. Intinya dia akan menangani dari perintah untuk keluar dari system secara konsisten. Standard POSIX, akan secara detail menerangkan tentang berbagai sinyal yang harus di tangani dalam proses keluar tersebut.

Menjalankan Program

Setelah menjalankan fork(), dua copy dari program yang sama akan jalan. Salah satu diantaranya biasanya akan meng-exec() program yang lain. System call exec() harus menemukan lokasi dari image binary dari file executable, me-load dan men-jalan-kannya. Kata "load" disini boleh tentu berarti "copy binary image ke memory", karena Linux mendukung demand loading.

Implementasi exec() di Linux mendukung beberapa format binary. Hal ini dapat dicapai melalui struktur linux_binfmt, dimana ada dua pointer ke fungsi -- satu untuk load executable dan yang lain untuk load library, setiap format binary me-representasikan executable maupun library. Loading dari shared library di implementasikan di source file yang sama dengan exec(), untuk sekarang kita fokus ke exec() saja.

Unix system memberikan programmer enam pola dari fungsi exec(). Semua kecuali satu dapat di implementasikan sebagai fungsi library, kernel Linux mengimplementasikan sys_execve() sendiri. Dia menjalankan tugas yang sangat sederhana, yaitu, load head dari executable, dan mencoba meng-execute-nya. Jika dua byte pertama adalah "#!", maka kalimat pertama akan di parsing dan interpreter akan di jalankan, selain itu format binary yang terdaftar akan berusaha di coba dijalankan.

Format Linux asli didukung secara langsung dalam fs/exec.c, dan fungsi yang relevan akan me-load binary aout_dan load library aout. Untuk binary, fungsi loading dari executable "a.out" akan berujung pada mmap() ke file disk, atau call read_exec(). mmap() digunakan oleh Linux jika dibutuhkan mekanisme loading ke page memory program saat di akses, sedangkan read_exec() digunakan jika memory mapping tidak didukung oleh filesystem host (contoh filesystem "msdos")

Kernel 1.1 memasukan revisi filesystem msdos, yang mendukung mmap(). Di samping itu, struct linux_binfmt menjadi linked list bukan sekedar array, untuk memungkinkan loading format binary baru sebagai kernel modul. Selanjutnya, structure yang ada juga di kembangkan untuk mengakses route core-dump yang berhubungan dengan format.

Akses ke File System

Kita semua tahu bahwa filesystem adalah sumber daya paling dasar dalam system Uniux, sangat mendasar dan ubiquitous sehingga membutuhkan nama yang mudah di ingat - untuk memudahkan kita akan menggunakan singkatan sederhana "fs".

Disini akan di asumsikan bahwa pembaca mengerti dasar fs Unix -- ijin akses, inode, superblock, mount dan umount. Konsep ini banyak di terangkan di literatur Unix lainnya. Kita akan banyak membahas isu spesifik fs di Linux.

Unix awal biasanya mendukung satu tipe fs saja, yang strukturnya tersebar dalam seluruh kernel. Pada hari ini, kita menggunakan interface standard antara kernel dengan fs, agar memudahkan pertukaran data pada berbagai arsitektur. Linux memberikan lapisan standard untuk menyampaikan informasi antara kernel dengan modul fs. Lapisan interface ini biasanya di sebut VFS, untuk "virtual filesystem".

Code filesystem oleh karenanya biasanya di pecah menjadi dua lapisan: lapisan atas memfokuskan diri pada manajemen dari tabel kernel dan struktur data, sedangkan lapisan bawah terdiri dari sekumpulan fungsi yang fs-dependent, yang di akses melalui struktur data VFS. Semua bagian yang fs-independent berada di file fs/*.c. Mereka menangani isu berikut ini:

  • Manaje buffer chache (buffer.c);
  • Respond ke system call fcntl() dan ioctl() (fcntl.c dan ioctl.c);
  • Memetakan pipe dan fifo pada inode dan buffer (fifo.c, pipe.c);
  • Manaje tabel file and inode (file_table.c, inode.c);
  • Lock dan unlock file dan record (locks.c);
  • Memetakan name ke inode (namei.c, open.c);
  • Implementasi fungsi select() (select.c) yang tricky;
  • Memberikan informasi (stat.c);
  • mount dan umount filesystem (super.c);
  • exec() executable dan dump core (exec.c);
  • Load berbagai format binary (bin_fmt*.c, seperti diterangkan diatas).

Interface VFS, terdiri dari sekumpulan operasi high-level yang di kerjakan oleh code fs-independent dan di lakukan oleh setiap tipe filesystem. Struktur yang paling relevan adalah inode_operations dan file_operations, meskipun mereka tidak sendiri karena beberapa struktur lain juga ada. Seluruh struktur di definisikan dalam include/linux/fs.h.

Pintu masuk dalam kernel ke file system yang sebenarnya ada di struktur file_system_type. Array file_system_types terdapat dalam fs/filesystems.c dan digunakan saat perintah mount diberikan. Fungsi read_super dari tipe fs yang relevan akan bertanggung jawab untuk mengisi struct super_block, yang akhirnya juga mengisi struct super_operations dan struct type_sb_info. struct super_operations memberikan pointer untuk operasi fs yang generik untuk fs-type current, struct type_sb_info memberikan informasi yang lebih spesifik tentang fs-type.

Array tipe filesystem sudah menjadi linked list, untuk membuka kemungkinan load tipe fs baru sebagai kernel module. Fungsi (un-)register_filesystem di masukan dalam fs/super.c.

Anatomi dari Tipe File System

Tugas dari filesystem type adalah untuk menjalankan tugas low-level yang di petakan ke operasi VFS yang lebih high level pada media fisik (disk, networ atau apa saja). Interface VFS cukup flexibel untuk mendukung filesystem Unix konvensional maupun yang tidak konvensional seperti msdos dan umsdos.

Setiap fs-type dibangun oleh hal berikut, di samping directory sendiri:

  • Entry ke array file_systems[] (fs/filesystems.c);
  • include file superblock (include/linux/type_fs_sb.h);
  • include file inode (include/linux/type_fs_i.h);
  • include file generic (include/linux/type_fs.h});
  • Dua #include dalam include/linux/fs.h, termasuk entry struct super_block dan struct inode.

Directory yang dimiliki oleh fs type berisi semua code, yang bertanggung jawab terhadap inode dan data management.

Untuk melihat dari dekat bagaimana low-level code dan interface VFS bekerja untuk fs type ada baiknya memnaca procfs. Source code fs/procfs cukup mudah dibaca.

Selanjutnya kita akan mencoba melihat mekanisme kerja di dalam VFS, minix filesystem akan digunakan sebagai contoh. minix type dipilih karena relatif kecil tapi cukup komplit; di samping itu, fs type linux lainnya diturunkan dari minix. ext2 type jauh lebih komplex mungkin bisa menjadi pelajaran bagi pembaca yang cukup tekun.

Pada saat minix-fs di mount, minix_akan membaca read_super dan mengisi struktur super_block dengan data yang dibaca dari device yang di mount. Parameter s_op dalam struktur tersebut akan menyimpan pointer ke minix_sops, yang digunakan oleh code filesystem generik yang dijalankan oleh operasi superblock.

Mengkaitkan fs yang baru saja di mount ke sistem tree global bergantung pada data berikut (asumsinya sb adalah struktur super_block dan dir_i point ke inode untuk mount point): 

sb->s_mounted point ke root-dir inode dari mounted filesystem (MINIX_ROOT_INO);
dir_i->i_mount menyimpan sb->s_mounted;
sb->s_covered menyimpan dir_i

Umount dapat dilakukan oleh do_umount, yang akan menjalankan minix_put_super.

Jika sebuah file di akses, minix_read_inode akan mulai bekerja; dia akan mengisi system-wide struktur inode dengan field dari minix_inode. Field inode->i_op akan di isi sesuai dengan inode->i_mode dan dia akan bertanggung jawab akan operasi selanjutnya pada file tersebut. Source untuk fungsi minix yang baru saja dijelasnkan dapat dilihat di fs/minix/inode.c.

Struktur inode_operations digunakan untuk menjalankan operasi inode ke fungsi kernel yang spesifik fs-type; entry pertama di struktur adalah pointer ke item file_operations, yang equivalen dengan data-management dari i_op. minix fs-type mengijinkan tiga instance dari inode-operation (untuk directori, untuk file dan untuk symbolic link) dan dua instance dari file-operation (symlinks tidak memerlukan hal ini).

Operasi directori (minix_readdir) dapat ditemukan di fs/minix/dir.c; operasi file (read dan write) ada di fs/minix/file.c dan operasi symlink (reading dan following link) ada di fs/minix/symlink.c.

Selebihnya dari minix directory mengimplementasikan tugas berikut:

  • bitmap.c mengatur alokasi dan pembebasan inode dan block (pada ext2 fs, hal ini dilakukan pada dua source file yang berbeda);
  • fsynk.c bertanggung jawab untuk system call fsync() -- dia mengatur block direct, indirect dan double indirect (ini merupakan bagian dari pengetahuan umum Unix);
  • namei.c berisi semua operasi nama pada inode, seperti membuat dan memhancurkan node, rename dan links;
  • truncate.c menjalankan pemotongan (truncatin) dari file.

console driver

Karena merupakan I/O device utama di sebagian besar Linux, console driver perlu memperoleh perhatian lebih. Source code dari console, maupun berbagai karakter driver, dapat ditemukan pada drivers/char, dan kita akan menggunakan directory tersebut sebagai titik referensi ketika melakukan penamaan file.

Inisialisasi Console dilakukan oleh fungsi tty_init(), di tty_io.c. Fungsi bertanggung jawab untuk memperoleh nomor device dan memanggil fungsi init untuk masing-masing device. con_init(), yang kemudian menghubungkan ke console, dan berada console.c.

Inisialisasi console telah berubah lumayan banyak pada evolusi 1.1. console_init() dilepas dari tty_init(), dan dapat di panggil secara langsung oleh ../../main.c. Virtual console dialokasikan secara dinamis.

Write ke console

Jika console device di tulis, fungsi con_write akan di jalankan. Fungsi ini mengatur semua control karakter dan escape sequences yang digunakan oleh aplikasi untuk memperoleh manajemen layar (screen) secara lengkap. escape sequence yang di implementasikan adalah milik terminal vt102; Hal ini berarti bahwa environment kita perlu di set TERM=vt102 jika kita melakukan telnet ke host non-Linux; untuk aktifitas lokal, lebih baik menggunakan TERM=console karena console Linux memberikan fungsi superset dari vt102.

con_write(), sebagian besar merupakan pernyataan nested switch, yang digunakan untuk meng-handel finite state automaton yang meng-interpretasikan escape sequences karakter satu per satu. Saat mode normal, character yang di cetak akan di tulis secara langsung ke memory video, menggunakan current attr-ibute. Dalam console.c, semua field struct vc dapat di akses melalui macro, oleh karenanya referensi ke (contoh) attr, sebetulnya me-refer ke field di struktur vc_cons[currcons], selama currcons adalah nomor dari console yang di referensikan.

Sebetulnya, vc_cons di kernel yang baru, tidak lagi berupa array dari struktur, dia berupa array dari pointer yang isinya di kmalloc() -kan. Penggunaan macro sangat menyederhanakan perubahan yang dilakukan, karena sebagian besar code tidak perlu di tulis ulang.

mapping dan unmapping dari console memory ke screen dilakukan oleh fungsi set_scrmem() (yang mengcopy data dari buffer console ke video memory) dan get_scrmem (yang mengcopydata kembali ke buffer console). buffer private dari current console secara fisik di map ke video RAM, untuk meminimalkan jumlah data yang perlu di transfer. Hal ini berarti, get- dan set-_scrmem() secara statik ada di console.c dan di panggil hanya saat console switch.

Read console

Membaca (read) console dilakukan melalui line-discipline. default (dan unique) line discipline di Linux di kenal sebagai tty_ldisc_N_TTY. line discipline adalah "men-displin input melalui line". Ini merupakan tabel fungsi, yang fokus untuk membaca device. Dengan di bantu oleh flag termios, line discipline mengontrol input dari tty: raw, cbreak dan cooked mode; select(); ioctl() dan sebagainya.

Fungsi read di line discipline di sebut read_chan(), yang akan membaca which tty buffer secara independent dari masukan yang ada. Alasannya, karena masuknya karakter melalui tty di tangani oleh interupsi hardware secara asinkron.

Line discipline N_TTY dapat ditemukan di tty_io.c, kernel selanjutnya akan menggunakan source file n_tty.c yang berbeda.

Bagian paling bawah dari console input adalah bagian dari manajemen keyboard, dan oleh karenanya akan di tangani dalam keyboard.c, dalam fungsi keyboard_interrupt().

Manajemen Keyboard

Majamen Keyboard cukup membuat kepala pusing. Oleh karenanya dia dibatasi di file keyboard.c, yang berisi banyak angka hexadecimal yang merepresentasikan banyak kode keyboard yang muncul di keyboard dari berbagai pembuat keyboard.

Bagi pembaca yang sangat tertarik dengan Linux keyboard, cara terbaik untuk membaca keyboard.c adalah mulai dari kalimat terakhir ke atas. Detail pada tingkat yang paling rendah terutama pada setengah pertama dari file tersebut.

Switching current console

current console di switch dengan cara mengaktifkan fungsi change_console(), yang berada di tty_io.c dan di aktifkan oleh keyboard.c dan vt.c (sebelumnya console switch untuk meresponds tombol keyboard yang di tekan, belakangan jika program me-request dengan cara memanggil ioctl()).

Proses switch yang sebenarnya dilakukan dalam dua langkah, dan fungsi complete_change_console() yang menangani langkah ke dua. Membagi switch berarti untuk menyelesaikan sebuah tugas sesudah terjadi handshake dengan proses yang mengontrol tty sesudah kita tinggalkan. Jika console tidak di bawah kontrol proses, call ke change_console() akan di selesaikan oleh complete_change_console() sendiri. Intervensi proses diperlukan untuk bisa melakukan switch secara baik antara console grafik dengan text dan sebaliknya, dan pada server X (sebagai contoh) dia akan mengontrol sendiri console grafik-nya.

Mekanisme seleksi (selection)

"selection" adalah fasilitas cut and paste untuk text console di Linux. Mekanisme ini biasanya di tangani oleh proses pada user-level, yang biasanya di inisiasi oleh selection atau gpm. Program pada user-level menggunakan ioctl() pada console untuk memberitahukan pada kernel untuk meng-highlight bagian pada layar. Text yang di select, kemudian akan di copy ke selection buffer. buffer ini merupakan entitas statik di console.c. Paste text dilakukan secara "manual" mem-push karakter di antrian tty input. Seluruh mekanisme selection di proteksi oleh #ifdef sehingga user dapat men-disable-nya saat konfigurasi kernel untuk menghemat beberapa kilobyte dari RAM.

Selection adalah fasilitas yang sangat low-level, dan dia bekerja secara tersembunyi dari aktifitas kernel lainnya. Hal ini berarti #ifdef hanya menghilangkan highlight sebelum screen di modifikasi.

Kernel yang baru mempunyai code yang lebih baik untuk selection, dan pointer mouse dapat di highlight secara independent oleh text yang di select. Selanjutnya, sejak versi 1.1.73 dan seterusnya digunakan dynamic buffer untuk text yang dipilih, membuat kernel 4kB lebih kecil.

ioctl() dari device

System call ioctl() merupakan pintu masuk untuk proses user untuk mengontrol perilaku sebuah file device. Manajemen ioctl di-spawn oleh ../../fs/ioctl.c, dimana sys_ioctl() yang sebenarnya berada. Permohonan standard ioctl akan ditangani di situ, permohonan yang berhubungan dengan file akan di proses oleh file_ioctl() (di source file yang sama), sedangkan proses lainnya akan di proses oleh fungsi ioctl() yang spesifik untuk device tersebut.

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.

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.

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.

Referensi

Pranala Menarik

Secara Umum

Instalasi Linux

Compile Kernel

Remaster Linux

Sistem Operasi untuk Embedded

Membuat Firmware Sendiri

Flash ke Device

Beberapa Tip

Tuning Kernel

Tuning Kernel Scheduler

Tuning I/O Scheduler

Tuning Manajemen Memory

Android

Membuat Kernel Module

Monitoring & Benchmark

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=OS:_Linux_Kernel&oldid=36945"