1. 程式人生 > >窺探 kernel,just for fun --- 系統呼叫過程分析

窺探 kernel,just for fun --- 系統呼叫過程分析

郵箱:[email protected]


過程分析:

1、系統呼叫需要一個使用者空間到核心空間的轉換,不同的平臺有不同的指令來完成這樣的轉換,這個指令也叫做作業系統陷入(operating systemtrap)指令。在linux中對於x86來說是用軟中斷0x80,也即是int $0x80。軟中斷由軟體指令觸發,硬中斷由硬體觸發。

通過軟中斷,系統會跳到一個預定的核心空間。它指向了系統呼叫處理程式(不是系統呼叫服務程式)system_call函式(arch/x86/kernel/entry32.h)。如上圖。

2、system_call到服務程式

顯然所有的系統呼叫都會跳到這個地址執行system_call函式。在執行int 0x80時系統呼叫號會被放入eax暫存器中。因為sys_call_table每個項佔用4個位元組。所以sys_call_table作為基地址,eax*4作為偏移量就可以找到對應的服務程式的地址。

系統呼叫的引數通過其他暫存器來傳遞。如

[cpp] view plaincopyprint?
  1. write(unsignedint fd,constchar *buf,size_t count)  

暫存器ebx,ecx,esi,edx來傳遞。但是前面我們說過,asmlinkage表示核心從堆疊中提取引數,而不是暫存器。因為在system_call執行時首先把這些暫存器壓入堆疊了。從下面的程式碼中就可找到答案~~~

[cpp] view plaincopyprint?
  1. ENTRY(system_call)  
  2.      RING0_INT_FRAME             # can't unwind into user spaceanyway  
  3.      pushl_cfi%eax              # save orig_eax  
  4.      SAVE_ALL  
  5.      GET_THREAD_INFO(%ebp)  
  6.                        #system call tracing in operation / emulation
  7.      testl$_TIF_WORK_SYSCALL_ENTRY,TI_flags(%ebp)  
  8.      jnzsyscall_trace_entry  
  9.      cmpl$(nr_syscalls), %eax  
  10.      jaesyscall_badsys  
  11. syscall_call:  
  12.      call*sys_call_table(,%eax,4)  

系統服務程式從堆疊中獲取引數,並修改,最後再通過堆疊返回修改後的數值。

不是所有的系統呼叫都有實際內容,如sys_ni_syscll在kernel/sys_ni.c中定義:

[cpp] view plaincopyprint?
  1. asmlinkage long sys_ni_syscall(void){  
  2. return -ENOSYS;  
  3. }  

你會發現在sys_call_table中sys_ni_syscall佔據了很多內容,其實它代表著已被淘汰的系統呼叫。

[cpp] view plaincopyprint?
  1. .longsys_ni_syscall   /* old stty syscallholder */
  2. .longsys_ni_syscall   /* old gtty syscallholder */
  3. .longsys_access  
  4. .longsys_nice  
  5. .longsys_ni_syscall   /* 35 - old ftime syscallholder */
  6. .longsys_sync  
  7. .longsys_kill  
  8. .longsys_rename  
  9. .longsys_mkdir  
  10. .longsys_rmdir        /* 40 */
  11. .longsys_dup  
  12. .longsys_pipe  
  13. .longsys_times  
  14. .longsys_ni_syscall   /* old prof syscallholder */

如上面可知sys_ni_syscall代替了不用的stty和gtty和prof。其實只要是被核心淘汰的系統呼叫都會被sys_ni_systcall代替。之所以這樣是為了老的程式在新的核心上執行時不至於出現大的問題。如不應呼叫這個系統呼叫卻呼叫了那個系統呼叫了。

相關推薦

窺探 kerneljust for fun --- 系統呼叫過程分析

郵箱:[email protected] 過程分析: 1、系統呼叫需要一個使用者空間到核心空間的轉換,不同的平臺有不同的指令來完成這樣的轉換,這個指令也叫做作業系統陷入(operating systemtrap)指令。在linux中對於x86

Linux系統呼叫過程分析

Linux系統呼叫過程分析 參考: 《Linux核心設計與實現》 0 摘要 linux的系統呼叫過程:層次例如以下:使用者程式------>C庫(即API):INT 0x80 ----->system_call------->系

Linux--Sys_Read系統呼叫過程分析

注: 本片文章以Read函式的呼叫為例來講述一下系統對塊驅動層的一些處理, 哈哈。如果有不正確或者不完善的地方,歡迎前來拍磚留言或者發郵件到[email protected]進行討論,先行謝過。 一.Read函式經由的層次模型 首先來了解一下Read函式經由的

Linux核心:基於int指令的經典系統呼叫過程分析

眾所周知,程式碼執行可以存在多種不同的特權級別,而針對Linux系統,即為:使用者模式(user mode)和核心模式(kernel mode)。在使用者模式下,CPU的功能空間受到極大的限制,是沒有權利訪問多少系統資源的,諸多關鍵資源的使用無法直接調配,如:硬

IT癡漢的工作現狀24-Just for fun

2010年 vmware 為什麽 space 眼界 項目 精神 技術 server 早在大學一開始我進行Linux的學習了,那時大家都跟Windows Xp玩的火熱,而我從來就不走平常路。在XP上安裝了VMware虛擬機搞起了Linux的探索。這簡直讓我眼界大開,每天

Just for fun的專欄

pip install Django==1.11.1 import django print(django.get_version()) 建立一個Django專案:django-admin startproject mysite python3 manage.py

Just for fun

哲學的發展: 從唯心主義到唯物主義,其原因就是隨著生產力的發展(尤為關鍵的食、行兩方面。農業的發展使得更多的人可以從體力勞動中脫離出來,從事對世界的思考、探索;交通工具的發展,使得思想的碰撞,更加頻繁,也使得思想轉播的更快,被更多的人接收和檢驗,而只有那些符合客觀規律的思想

Linux 之父自傳《just for fun》讀書筆記

一次偶然的機會,看到了阮一峰老師關於這本書的介紹,當時我就覺得這本書相當有趣。 在沒有讀這本書之前,我覺得 linus 作為發明 Linux 系統的人,應該是一個比較嚴肅的人,就像我的老師一樣。但事實跟我想象的相反,他跟程式設計師一樣,風趣幽默,各種自嘲(他已經在書中不少於一次說自己的鼻子大了),專注於技術

Just For Fun

題目連結 題目大意可轉化為, 給出一系列區間[a, b], 將這些點按照區間重疊數目來排序. 如果直接暴力, 每次回遍歷(b-a)次, 直接超時. a, b兩點正好是跳變點,

arm linux 系統呼叫過程

在Linux下系統呼叫是用軟中斷實現的,下面以一個簡單的open例子簡要分析一下應用層的open是如何呼叫到核心中的sys_open的。 t8.c 1: #include <stdio.h> 2: #include <sys/types.h> 3:

Linux fsync和fdatasync系統呼叫實現分析(Ext4檔案系統

參考:https://blog.csdn.net/luckyapple1028/article/details/61413724 在Linux系統中,對檔案系統上檔案的讀寫一般是通過頁快取(page cache)進行的(DirectIO除外),這樣設計的可以延時磁碟IO的操作,從而可以減少磁碟讀

win10系統呼叫架構分析

1.  作業系統模型 大多數作業系統中,都會把應用程式和核心程式碼分離執行在不同的模式下。核心模式訪問系統資料和硬體,應用程式執行在沒有特權的模式下(使用者模式),只能使用有限的API,且不能直接訪問硬體。當用戶模式呼叫系統服務時,CPU執行一個特殊的指令以切換到核

Linux系統呼叫系統呼叫過程

對於日常使用的應用也不是脫離了硬體進行執行的,為了方便使用,就出現了作業系統,如果作業系統不是開放的,那就失去了作業系統的意義,為了方便使用作業系統,作業系統預留出了一些介面,這些介面就是系統呼叫函式。 當然系統呼叫函式肯定不同於庫函式,接下來我將講解Linux中的系統呼叫過程。 下圖是軟硬

brk系統呼叫實現分析

brk(addr)直接修改堆的大小。addr指定current->mm->brk的新值,返回值是線性區新的結束地址,這是一個系統呼叫。當用戶態的程序呼叫brk()系統呼叫時,核心執行sys_brk(addr)函式。下面分析這個函式的執行流程:1:檢測addr引數是

arm linux 系統呼叫過程

在Linux下系統呼叫是用軟中斷實現的,下面以一個簡單的open例子簡要分析一下應用層的open是如何呼叫到核心中的sys_open的。 t8.c 1: #include <stdio.h> 2: #include <sys/types.

Linux核心分析(五)系統呼叫過程解析

禹曉博+ 原創作品轉載請註明出處 + 歡迎加入《Linux核心分析》MOOC網易雲課堂學習 一、系統呼叫流程分析         系統呼叫系統呼叫就是使用者空間應用程式和核心提供的服務之間的一個介面。由於服務是在核心中提供的,因此無法執行直接呼叫;相反,我們必須使用一個程序

系統呼叫過程詳解

在上一篇部落格中,我們介紹了庫函式和系統呼叫的聯絡和區別。在這篇部落格中,我們將通過分析Linux0.11的原始碼來理解系統呼叫的實際執行過程。 整個過程如下:首先指令流執行到系統呼叫函式時,系統呼叫函式通過int 0x80指令進入系統呼叫入口程式,並且把系統呼叫號放入%e

Socket與系統呼叫深度分析

學習一下對Socket與系統呼叫的分析分析 一、介紹 我們都知道高階語言的網路程式設計最終的實現都是呼叫了系統的Socket API程式設計介面,在作業系統提供的socket系統介面之上可以建立不同埠之間的網路連線,從而使我們可以編寫各基於不同網路協議的應用程式。而使用者程式一般都是執行在使用者態,依靠的So

linux 系統啟動過程分析

系統root 密碼丟失故障 linux啟動順序主板BIOS加電自檢 檢查硬件--> 讀取硬盤引導扇區(MBR)--> 啟動引導程序(grub)--> 選擇系統--> 加載系統內核(kernel shell)--> 啟動系統讀取相應的默認設置(環境變量,運行級別)--

Java中的方法呼叫過程分析

假設呼叫x.f(args),隱式引數x宣告為類C的一個例項物件: 1.編譯器檢視物件的宣告型別和方法名。例如,可能存在方法f(int)和方法f(String)。編譯器將會一一列舉出所有該類中名為f的方法和其超類中訪問屬性為public且名為f的方法。 2.編譯器將檢視呼叫方法時提供的引數型別