linuxatomich

❶ linux設備驅動程序如何與硬體通信

LINUX設備驅動程序是怎麼樣和硬體通信的?下面將由我帶大家來解答這個疑問吧，希望對大家有所收獲!

LINUX設備驅動程序與硬體設備之間的通信

設備驅動程序是軟體概念和硬體電路之間的一個抽象層，因此兩方面都要討論。到目前為止，我們已經討論詳細討論了軟體概念上的一些細節，現在討論另一方面，介紹驅動程序在Linux上如何在保持可移植性的前提下訪問I/O埠和I/O內存。

我們在需要示例的場合會使用簡單的數字I/O埠來講解I/O指令，並使用普通的幀緩沖區顯存來講解內存映射I/O。

I/O埠和I/O內存

計算機對每種外設都是通過讀寫它的寄存器進行控制的。大部分外設都有幾個寄存器，不管是在內存地址空間還是在I/O地址空間，這些寄存器的訪問地址都是連續的。

I/O埠就是I/O埠，設備會把寄存器映射到I/O埠，不管處理器是否具有獨立的I/O埠地址空間。即使沒有在訪問外設時也要模擬成讀寫I/O埠。

I/O內存是設備把寄存器映射到某個內存地址區段(如PCI設備)。這種I/O內存通常是首先方案，它不需要特殊的處理器指令，而且CPU核心訪問內存更有效率。

I/O寄存器和常規內存

盡管硬體寄存器和內存非常相似，但程序員在訪問I/O寄存器的時候必須注意避免由於CPU或編譯器不恰當的優化而改變預期的I/O動作。

I/O寄存器和RAM最主要的區別就是I/O操作具有邊際效應，而內存操作則沒有：由於內存沒有邊際效應，所以可以用多種 方法 進行優化，如使用高速緩存保存數值、重新排序讀/寫指令等。

編譯器能夠將數值緩存在CPU寄存器中而不寫入內存，即使儲存數據，讀寫操作也都能在高速緩存中進行而不用訪問物理RAM。無論是在編譯器一級或是硬體一級，指令的重新排序都有可能發生：一個指令序列如果以不同於程序文本中的次序運行常常能執行得更快。

在對常規內存進行這些優化的時候，優化過程是透明的，而且效果良好，但是對I/O操作來說這些優化很可能造成致命的錯誤，這是因為受到邊際效應的干擾，而這卻是驅動程序訪問I/O寄存器的主要目的。處理器無法預料某些 其它 進程(在另一個處理器上運行，或在在某個I/O控制器中發生的操作)是否會依賴於內存訪問的順序。編譯器或CPU可能會自作聰明地重新排序所要求的操作，結果會發生奇怪的錯誤，並且很難調度。因此，驅動程序必須確保不使用高速緩沖，並且在訪問寄存器時不發生讀或寫指令的重新排序。

由硬體自身引起的問題很解決：只要把底層硬體配置成(可以是自動的或是由Linux初始化代碼完成)在訪問I/O區域(不管是內存還是埠)時禁止硬體緩存即可。

由編譯器優化和硬體重新排序引起的問題的解決辦法是：對硬體(或其他處理器)必須以特定順序的操作之間設置內存屏障(memory barrier)。Linux提供了4個宏來解決所有可能的排序問題：

#include <linux/kernel.h>

void barrier(void)

這個函數通知編譯器插入一個內存屏障，但對硬體沒有影響。編譯後的代碼會把當前CPU寄存器中的所有修改過的數值保存到內存中，需要這些數據的時候再重新讀出來。對barrier的調用可避免在屏障前後的編譯器優化，但硬體完成自己的重新排序。

#include <asm/system.h>

void rmb(void);

void read_barrier_depends(void);

void wmb(void);

void mb(void);

這些函數在已編譯的指令流中插入硬體內存屏障;具體實現方法是平台相關的。rmb(讀內存屏障)保證了屏障之前的讀操作一定會在後來的讀操作之前完成。wmb保證寫操作不會亂序，mb指令保證了兩者都不會。這些函數都是barrier的超集。

void smp_rmb(void);

void smp_read_barrier_depends(void);

void smp_wmb(void);

void smp_mb(void);

上述屏障宏版本也插入硬體屏障，但僅僅在內核針對SMP系統編譯時有效;在單處理器系統上，它們均會被擴展為上面那些簡單的屏障調用。

設備驅動程序中使用內存屏障的典型形式如下：

writel(dev->registers.addr, io_destination_address);

writel(dev->registers.size, io_size);

writel(dev->registers.operation, DEV_READ);

wmb();

writel(dev->registers.control, DEV_GO);

在這個例子中，最重要的是要確保控制某種特定操作的所有設備寄存器一定要在操作開始之前已被正確設置。其中的內存屏障會強制寫操作以要求的順序完成。

因為內存屏障會影響系統性能，所以應該只用於真正需要的地方。不同類型的內存屏障對性能的影響也不盡相同，所以最好盡可能使用最符合需要的特定類型。

值得注意的是，大多數處理同步的內核原語，如自旋鎖和atomic_t操作，也能作為內存屏障使用。同時還需要注意，某些外設匯流排(比如PCI匯流排)存在自身的高速緩存問題，我們將在後面的章節中討論相關問題。

在某些體系架構上，允許把賦值語句和內存屏障進行合並以提高效率。內核提供了幾個執行這種合並的宏，在默認情況下，這些宏的定義如下：

#define set_mb(var, value) do {var = value; mb();} while 0

#define set_wmb(var, value) do {var = value; wmb();} while 0

#define set_rmb(var, value) do {var = value; rmb();} while 0

在適當的地方，<asm/system.h>中定義的這些宏可以利用體系架構特有的指令更快的完成任務。注意只有小部分體系架構定義了set_rmb宏。

使用I/O埠

I/O埠是驅動程序與許多設備之間的通信方式——至少在部分時間是這樣。本節講解了使用I/O埠的不同函數，另外也涉及到一些可移植性問題。

I/O埠分配

下面我們提供了一個注冊的介面，它允允許驅動程序聲明自己需要操作的埠：

#include <linux/ioport.h>

struct resource *request_region(unsigned long first, unsigned long n, const char *name);

它告訴內核，我們要使用起始於first的n個埠。name是設備的名稱。如果分配成功返回非NULL，如果失敗返回NULL。

所有分配的埠可從/proc/ioports中找到。如果我們無法分配到我們要的埠集合，則可以查看這個文件哪個驅動程序已經分配了這些埠。

如果不再使用這些埠，則用下面函數返回這些埠給系統：

void release_region(unsigned long start, unsigned long n);

下面函數允許驅動程序檢查給定的I/O埠是否可用：

int check_region(unsigned long first, unsigned long n);//不可用返回負的錯誤代碼

我們不贊成用這個函數，因為它返回成功並不能確保分配能夠成功，因為檢查和其後的分配並不是原子操作。我們應該始終使用request_region，因為這個函數執行了必要的鎖定，以確保分配過程以安全原子的方式完成。

操作I/O埠

當驅動程序請求了需要使用的I/O埠范圍後，必須讀取和/或寫入這些埠。為此，大多數硬體都會把8位、16位、32位區分開來。它們不能像訪問系統內存那樣混淆使用。

因此，C語言程序必須調用不同的函數訪問大小不同的埠。那些只支持映射的I/O寄存器的計算機體系架構通過把I/O埠地址重新映射到內存地址來偽裝埠I/O，並且為了易於移植，內核對驅動程序隱藏了這些細節。Linux內核頭文件中(在與體系架構相關的頭文件<asm/io.h>中)定義了如下一些訪問I/O埠的內聯函數：

unsigned inb(unsigned port);

void outb(unsigned char byte, unsigned port);

位元組讀寫埠。

unsigned inw(unsigned port);

void outw(unsigned short word, unsigned port);

訪問16位埠

unsigned inl(unsigned port);

void outl(unsigned longword, unsigned port);

訪問32位埠

在用戶空間訪問I/O埠

上面這些函數主要是提供給設備驅動程序使用的，但它們也可以用戶空間使用，至少在PC類計算機上可以使用。GNU的C庫在<sys/io.h>中定義了這些函數。如果要要用戶空間使用inb及相關函數，則必須滿足正下面這些條件：

編譯程序時必須帶有-O選項來強制內聯函數的展開。

必須用ioperm(獲取單個埠的許可權)或iopl(獲取整個I/O空間)系統調用來獲取對埠進行I/O操作的許可權。這兩個函數都是x86平台特有的。

必須以root身份運行該程序才能調用ioperm或iopl。或者進程的祖先進程之一已經以root身份獲取對埠的訪問。

如果宿主平台沒有以上兩個系統調用，則用戶空間程序仍然可以使用/dev/port設備文件訪問I/O埠。不過要注意，該設備文件的含義與平台密切相關，並且除PC平台以處，它幾乎沒有什麼用處。

串操作

以上的I/O操作都是一次傳輸一個數據，作為補充，有些處理器實現了一次傳輸一個數據序列的特殊指令，序列中的數據單位可以是位元組、字、雙字。這些指令稱為串操作指令，它們執行這些任務時比一個C語言編寫的循環語句快得多。下面列出的宏實現了串I/O：

void insb(unsigned port, void *addr, unsigned long count);

void outsb(unsigned port, void *addr, unsigned long count);從內存addr開始連續讀/寫count數目的位元組。只對單一埠port讀取或寫入數據

void insw(unsigned port, void *addr, unsigned long count);

void outsw(unsigned port, void *addr, unsigned long count);對一個16位埠讀寫16位數據

void insl(unsigned port, void *addr, unsigned long count);

void outsl(unsigned port, void *addr, unsigned long count);對一個32位埠讀寫32位數據

在使用串I/O操作函數時，需要銘記的是：它們直接將位元組流從埠中讀取或寫入。因此，當埠和主機系統具有不同的位元組序時，將導致不可預期的結果。使用inw讀取埠將在必要時交換位元組，以便確保讀入的值匹配於主機的位元組序。然而，串函數不會完成這種交換。

暫停式I/O

在處理器試圖從匯流排上快速傳輸數據時，某些平台(特別是i386)就會出現問題。當處理器時鍾比外設時鍾(如ISA)快時就會出現問題，並且在設備板上特別慢時表現出來。為了防止出現丟失數據的情況，可以使用暫停式的I/O函數來取代通常的I/O函數，這些暫停式的I/O函數很像前面介紹的那些I/O函數，不同之處是它們的名字用_p結尾，如inb_p、outb_p等等。在linux支持的大多數平台上都定義了這些函數，不過它們常常擴展為非暫停式I/O同樣的代碼，因為如果不使用過時的外設匯流排就不需要額外的暫停。

平台相關性

I/O指令是與處理器密切相關的。因為它們的工作涉及到處理器移入移出數據的細節，所以隱藏平台間的差異非常困難。因此，大部分與I/O埠相關的源代碼都與平台相關。

回顧前面函數列表可以看到有一處不兼容的地方，即數據類型。函數的參數根據各平台體系架構上的不同要相應地使用不同的數據類型。例如，port參數在x86平台上(處理器只支持64KB的I/O空間)上定義為unsigned short，但在其他平台上定義為unsigned long，在這些平台上，埠是與內存在同一地址空間內的一些特定區域。

感興趣的讀者可以從io.h文件獲得更多信息，除了本章介紹的函數，一些與體系架構相關的函數有時也由該文件定義。

值得注意的是，x86家族之外的處理器都不為埠提供獨立的地址空間。

I/O操作在各個平台上執行的細節在對應平台的編程手冊中有詳細的敘述;也可以從web上下載這些手冊的PDF文件。

I/O埠示例

演示設備驅動程序的埠I/O的示例代碼運行於通用的數字I/O埠上，這種埠在大多數計算機平台上都能找到。

數字I/O埠最常見的一種形式是一個位元組寬度的I/O區域，它或者映射到內存，或者映射到埠。當把數字寫入到輸出區域時，輸出引腳上的電平信號隨著寫入的各位而發生相應變化。從輸入區域讀取到的數據則是輸入引腳各位當前的邏輯電平值。

這類I/O埠的具體實現和軟體介面是因系統而異的。大多數情況下，I/O引腳由兩個I/O區域控制的：一個區域中可以選擇用於輸入和輸出的引腳，另一個區域中可以讀寫實際的邏輯電平。不過有時情況簡單些，每個位不是輸入就是輸出(不過這種情況下就不能稱為“通用I/O"了);在所有個人計算機上都能找到的並口就是這樣的非通用的I/O埠。

並口簡介

並口的最小配置由3個8位埠組成。第一個埠是一個雙向的數據寄存器，它直接連接到物理連接器的2~9號引腳上。第二個埠是一個只讀的狀態寄存器;當並口連接列印機時，該寄存器 報告 列印機狀態，如是否是線、缺紙、正忙等等。第三個埠是一個只用於輸出的控制寄存器，它的作用之一是控制是否啟用中斷。

如下所示：並口的引腳

示例驅動程序

while(count--) {

outb(*(ptr++), port);

wmb();

}

使用I/O內存

除了x86上普遍使的I/O埠之外，和設備通信的另一種主要機制是通過使用映射到內存的寄存器或設備內存，這兩種都稱為I/O內存，因為寄存器和內存的差別對軟體是透明的。

I/O內存僅僅是類似RAM的一個區域，在那裡處理器可以通過匯流排訪問設備。這種內存有很多用途，比如存放視頻數據或乙太網數據包，也可以用來實現類似I/O埠的設備寄存器(也就是說，對它們的讀寫也存在邊際效應)。

根據計算機平台和所使用匯流排的不同，i/o內存可能是，也可能不是通過頁表訪問的。如果訪問是經由頁表進行的，內核必須首先安排物理地址使其對設備驅動程序可見(這通常意味著在進行任何I/O之前必須先調用ioremap)。如果訪問無需頁表，那麼I/O內存區域就非常類似於I/O埠，可以使用適當形式的函數讀取它們。

不管訪問I/O內存是否需要調用ioremap，都不鼓勵直接使用指向I/O內存的指針。相反使用包裝函數訪問I/O內存，這一方面在所有平台上都是安全的，另一方面，在可以直接對指針指向的內存區域執行操作的時候，這些函數是經過優化的。並且直接使用指針會影響程序的可移植性。

I/O內存分配和映射

在使用之前，必須首先分配I/O區域。分配內存區域的介面如下(在<linux/ioport.h>中定義)：

struct resource *request_mem_region(unsigned long start, unsigned long len, char *name);

該函數從start開始分配len位元組長的內存區域。如果成功返回非NULL，否則返回NULL值。所有的I/O內存分配情況可從/proc/iomem得到。

不再使用已分配的內存區域時，使用如下介面釋放：

void release_mem_region(unsigned long start, unsigned long len);

下面函數用來檢查給定的I/O內存區域是否可用的老函數：

int check_mem_region(unsigned long start, unsigned long len);//這個函數和check_region一樣不安全，應避免使用

分配內存之後我們還必須確保該I/O內存對內存而言是可訪問的。獲取I/O內存並不意味著可引用對應的指針;在許多系統上，I/O內存根本不能通過這種方式直接訪問。因此，我們必須由ioremap函數建立映射，ioremap專用於為I/O內存區域分配虛擬地址。

我們根據以下定義來調用ioremap函數：

#include <asm/io.h>

void *ioremap(unsigned long phys_addr, unsigned long size);

void *ioremap_nocache(unsigned long phys_addr, unsigned long size);在大多數計算機平台上，該函數和ioremap相同：當所有I/O內存已屬於非緩存地址時，就沒有必要實現ioremap的獨立的，非緩沖版本。

void iounmap(void *addr);

記住，由ioremap返回的地址不應該直接引用，而應該使用內核提供的accessor函數。

訪問I/O內存

在某些平台上我們可以將ioremap的返回值直接當作指針使用。但是，這種使用不具有可移植性，訪問I/O內存的正確方法是通過一組專用於些目的的函數(在<asm/io.h>中定義)。

從I/O內存中讀取，可使用以下函數之一：

unsigned int ioread8(void *addr);

unsigned int ioread16(void *addr);

unsigned int ioread32(void *addr);

其中，addr是從ioremap獲得的地址(可能包含一個整數偏移量);返回值是從給定I/O內存讀取到的值。

寫入I/O內存的函數如下：

void iowrite8(u8 value, void *addr);

void iowrite16(u16 value, void *addr);

void iowrite32(u32 value, void *addr);

如果必須在給定的I/O內存地址處讀/寫一系列值，則可使用上述函數的重復版本：

void ioread8_rep(void *addr, void *buf, unsigned long count);

void ioread16_rep(void *addr, void *buf, unsigned long count);

void ioread32_rep(void *addr, void *buf, unsigned long count);

void iowrite8_rep(void *addr, const void *buf, unsigned long count);

void iowrite16_rep(void *addr, const void *buf, unsigned long count);

void iowrite32_rep(void *addr, const void *buf, unsigned long count);

上述函數從給定的buf向給定的addr讀取或寫入count個值。count以被寫入數據的大小為單位。

上面函數均在給定的addr處執行所有的I/O操作，如果我們要在一塊I/O內存上執行操作，則可以使用下面的函數：

void memset_io(void *addr, u8 value, unsigned int count);

void memcpy_fromio(void *dest, void *source, unsigned int count);

void memcpy_toio(void *dest, void *source, unsigned int count);

上述函數和C函數庫的對應函數功能一致。

像I/O內存一樣使用I/O埠

某些硬體具有一種有趣的特性：某些版本使用I/O埠，而其他版本則使用I/O內存。導出給處理器的寄存器在兩種情況下都是一樣的，但訪問方法卻不同。為了讓處理這類硬體的驅動程序更加易於編寫，也為了最小化I/O埠和I/O內存訪問這間的表面區別，2.6內核引入了ioport_map函數：

void *ioport_map(unsigned long port, unsigned int count);

該函數重新映射count個I/O埠，使其看起來像I/O內存。此後，驅動程序可在該函數返回的地址上使用ioread8及其相關函數，這樣就不必理會I/O埠和I/O內存之間的區別了。

當不需要這種映射時使用下面函數一撤消：

void ioport_unmap(void *addr);

這些函數使得I/O埠看起來像內存。但需要注意的是，在重新映射之前，我們必須通過request_region來分配這些I/O埠。

為I/O內存重用short

前面介紹的short示例模塊訪問的是I/O埠，它也可以訪問I/O內存。為此必須在載入時通知它使用I/O內存，另外還要修改base地址以使其指向I/O區域。

下例是在MIPS開發板上點亮調試用的LED：

mips.root# ./short_load use_mem=1 base = 0xb7ffffc0

mips.root# echo -n 7 > /dev/short0

下面代碼是short寫入內存區域時使用的循環：

while(count--) {

iowrite8(*ptr++, address);

wmb();

}

1MB地址空間之下的ISA內存

最廣為人知的I/O內存區之一就是個人計算機上的ISA內存段。它的內存范圍在64KB(0xA0000)到1MB(0x100000)之間，因此它正好出現在常規系統RAM的中間。這種地址看上去有點奇怪，因為這個設計決策是20世紀80年代早期作出的，在當時看來沒有人會用到640KB以上的內存。

❷ 在linux的用戶空間，有沒有原子操作的函數

有。函數如下：

1. 定義在include/asm/atomic.h中。 用戶程序include它，在自己控制CONFIG_SMP定義。

2. 在單處理器時 atomic_inc() 就是incl xxxx
   在CONFIG_SMP時， atomic_inc()是 lock incl xxxx

3. 因此incl XXXX在SMP時不是原子的。必須用lock.
   

❸ linux內核同步問題

Linux內核設計與實現 十、內核同步方法

手把手教Linux驅動5-自旋鎖、信號量、互斥體概述

== 基礎概念： ==

並發 ：多個執行單元同時進行或多個執行單元微觀串列執行，宏觀並行執行

競態 ：並發的執行單元對共享資源（硬體資源和軟體上的全局變數）的訪問而導致的竟態狀態。

臨界資源 ：多個進程訪問的資源

臨界區 ：多個進程訪問的代碼段

== 並發場合： ==

1、單CPU之間進程間的並發 :時間片輪轉，調度進程。 A進程訪問列印機，時間片用完，OS調度B進程訪問列印機。

2、單cpu上進程和中斷之間並發 ：CPU必須停止當前進程的執行中斷;

3、多cpu之間

4、單CPU上中斷之間的並發

== 使用偏向： ==

==信號量用於進程之間的同步，進程在信號量保護的臨界區代碼裡面是可以睡眠的（需要進行進程調度），這是與自旋鎖最大的區別。==

信號量又稱為信號燈，它是用來協調不同進程間的數據對象的，而最主要的應用是共享內存方式的進程間通信。本質上，信號量是一個計數器，它用來記錄對某個資源（如共享內存）的存取狀況。它負責協調各個進程，以保證他們能夠正確、合理的使用公共資源。它和spin lock最大的不同之處就是：無法獲取信號量的進程可以睡眠，因此會導致系統調度。

1、==用於進程與進程之間的同步==

2、==允許多個進程進入臨界區代碼執行，臨界區代碼允許睡眠；==

3、信號量本質是==基於調度器的==，在UP和SMP下沒有區別；進程獲取不到信號量將陷入休眠，並讓出CPU；

4、不支持進程和中斷之間的同步

5、==進程調度也是會消耗系統資源的，如果一個int型共享變數就需要使用信號量，將極大的浪費系統資源==

6、信號量可以用於多個線程，用於資源的計數（有多種狀態）

==信號量加鎖以及解鎖過程：==

sema_init(&sp->dead_sem, 0); / 初始化 /

down(&sema);

臨界區代碼

up(&sema);

==信號量定義：==

==信號量初始化：==

==dowm函數實現：==

==up函數實現：==

信號量一般可以用來標記可用資源的個數。

舉2個生活中的例子：

==dowm函數實現原理解析：==

（1）down

判斷sem->count是否 > 0，大於0則說明系統資源夠用，分配一個給該進程，否則進入__down(sem);

（2）__down

調用__down_common(sem, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);其中TASK_UNINTERRUPTIBLE=2代表進入睡眠，且不可以打斷；MAX_SCHEDULE_TIMEOUT休眠最長LONG_MAX時間；

（3）list_add_tail(&waiter.list, &sem->wait_list);

把當前進程加入到sem->wait_list中；

（3）先解鎖後加鎖;

進入__down_common前已經加鎖了，先把解鎖，調用schele_timeout(timeout)，當waiter.up=1後跳出for循環；退出函數之前再加鎖；

Linux內核ARM構架中原子變數的底層實現研究

rk3288 原子操作和原子位操作

原子變數適用於只共享一個int型變數；

1、原子操作是指不被打斷的操作，即它是最小的執行單位。

2、最簡單的原子操作就是一條條的匯編指令(不包括一些偽指令，偽指令會被匯編器解釋成多條匯編指令)

==常見函數：==

==以atomic_inc為例介紹實現過程==

在Linux內核文件archarmincludeasmatomic.h中。 執行atomic_read、atomic_set這些操作都只需要一條匯編指令，所以它們本身就是不可打斷的。 需要特別研究的是atomic_inc、atomic_dec這類讀出、修改、寫回的函數。

所以atomic_add的原型是下面這個宏：

atomic_add等效於：

result（%0） tmp（%1） (v->counter)（%2） (&v->counter)（%3） i（%4）

注意：根據內聯匯編的語法，result、tmp、&v->counter對應的數據都放在了寄存器中操作。如果出現上下文切換，切換機制會做寄存器上下文保護。

（1）ldrex %0, [%3]

意思是將&v->counter指向的數據放入result中，並且（分別在Local monitor和Global monitor中）設置獨占標志。

（2）add %0, %0, %4

result = result + i

（3）strex %1, %0, [%3]

意思是將result保存到&v->counter指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。

（4） teq %1, #0

測試strex是否成功（tmp == 0 ？？）

（5）bne 1b

如果發現strex失敗，從（1）再次執行。

Spinlock 是內核中提供的一種比較常見的鎖機制，==自旋鎖是「原地等待」的方式解決資源沖突的==，即，一個線程獲取了一個自旋鎖後，另外一個線程期望獲取該自旋鎖，獲取不到，只能夠原地「打轉」（忙等待）。由於自旋鎖的這個忙等待的特性，註定了它使用場景上的限制 —— 自旋鎖不應該被長時間的持有（消耗 CPU 資源），一般應用在==中斷上下文==。

1、spinlock是一種死等機制

2、信號量可以允許多個執行單元進入，spinlock不行，一次只能允許一個執行單元獲取鎖，並且進入臨界區，其他執行單元都是在門口不斷的死等

3、由於不休眠，因此spinlock可以應用在中斷上下文中；

4、由於spinlock死等的特性，因此臨界區執行代碼盡可能的短；

==spinlock加鎖以及解鎖過程：==

spin_lock(&devices_lock);

臨界區代碼

spin_unlock(&devices_lock);

==spinlock初始化==

==進程和進程之間同步==

==本地軟中斷之間同步==

==本地硬中斷之間同步==

==本地硬中斷之間同步並且保存本地中斷狀態==

==嘗試獲取鎖==

== arch_spinlock_t結構體定義如下： ==

== arch_spin_lock的實現如下： ==

lockval（%0） newval（%1） tmp（%2） &lock->slock（%3） 1 << TICKET_SHIFT（%4）

（1）ldrex %0, [%3]

把lock->slock的值賦值給lockval；並且（分別在Local monitor和Global monitor中）設置獨占標志。

（2）add %1, %0, %4

newval =lockval +（1<<16）; 相當於next+1；

（3）strex %2, %1, [%3]

newval =lockval +（1<<16）; 相當於next+1；

意思是將newval保存到 &lock->slock指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。

（4） teq %2, #0

測試strex是否成功

（5）bne 1b

如果發現strex失敗，從（1）再次執行。

通過上面的分析，可知關鍵在於strex的操作是否成功的判斷上。而這個就歸功於ARM的Exclusive monitors和ldrex/strex指令的機制。

（6）while (lockval.tickets.next != lockval.tickets.owner)

如何lockval.tickets的next和owner是否相等。相同則跳出while循環，否則在循環內等待判斷；

* （7）wfe()和smp_mb() 最終調用#define barrier() asm volatile ("": : :"memory") *

阻止編譯器重排，保證編譯程序時在優化屏障之前的指令不會在優化屏障之後執行。

== arch_spin_unlock的實現如下： ==

退出鎖時：tickets.owner++

== 出現死鎖的情況： ==

1、擁有自旋鎖的進程A在內核態阻塞了，內核調度B進程，碰巧B進程也要獲得自旋鎖，此時B只能自旋轉。 而此時搶占已經關閉，（單核）不會調度A進程了，B永遠自旋，產生死鎖。

2、進程A擁有自旋鎖，中斷到來，CPU執行中斷函數，中斷處理函數，中斷處理函數需要獲得自旋鎖，訪問共享資源，此時無法獲得鎖，只能自旋，產生死鎖。

== 如何避免死鎖： ==

1、如果中斷處理函數中也要獲得自旋鎖，那麼驅動程序需要在擁有自旋鎖時禁止中斷；

2、自旋鎖必須在可能的最短時間內擁有

3、避免某個獲得鎖的函數調用其他同樣試圖獲取這個鎖的函數，否則代碼就會死鎖；不論是信號量還是自旋鎖，都不允許鎖擁有者第二次獲得這個鎖，如果試圖這么做，系統將掛起；

4、鎖的順序規則（a) 按同樣的順序獲得鎖；b) 如果必須獲得一個局部鎖和一個屬於內核更中心位置的鎖，則應該首先獲取自己的局部鎖 ;c) 如果我們擁有信號量和自旋鎖的組合，則必須首先獲得信號量；在擁有自旋鎖時調用down(可導致休眠)是個嚴重的錯誤的；）

== rw（read/write）spinlock： ==

加鎖邏輯：

1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入

2、假設臨界區內有一個讀線程，這時候信賴的read線程可以任意進入，但是寫線程不能進入；

3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；

4、假設臨界區內有一個或者多個讀線程，寫線程不可以進入臨界區，但是寫線程也無法阻止後續的讀線程繼續進去，要等到臨界區所有的讀線程都結束了，才可以進入，可見：==rw（read/write）spinlock更加有利於讀線程；==

== seqlock（順序鎖）： ==

加鎖邏輯：

1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入

2、假設臨界區內沒有寫線程的情況下，read線程可以任意進入；

3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；

4、假設臨界區內只有read線程的情況下，寫線程可以理解執行，不會等待，可見：==seqlock（順序鎖）更加有利於寫線程；==

讀寫速度 ： CPU > 一級緩存 > 二級緩存 > 內存 ，因此某一個CPU0的lock修改了，其他的CPU的lock就會失效；那麼其他CPU就會依次去L1 L2和主存中讀取lock值，一旦其他CPU去讀取了主存，就存在系統性能降低的風險；

mutex用於互斥操作。

互斥體只能用於一個線程，資源只有兩種狀態（佔用或者空閑）

1、mutex的語義相對於信號量要簡單輕便一些，在鎖爭用激烈的測試場景下，mutex比信號量執行速度更快，可擴展

性更好，

2、另外mutex數據結構的定義比信號量小;、

3、同一時刻只有一個線程可以持有mutex

4、不允許遞歸地加鎖和解鎖

5、當進程持有mutex時，進程不可以退出。

• mutex必須使用官方API來初始化。

• mutex可以睡眠，所以不允許在中斷處理程序或者中斷下半部中使用，例如tasklet、定時器等

==常見操作：==

struct mutex mutex_1;

mutex_init(&mutex_1);

mutex_lock(&mutex_1)

臨界區代碼；

mutex_unlock(&mutex_1)

==常見函數：==

=

❹ linux源代碼，求詳細分析，代碼如下，來自 /mm: filemap.h

找到了個帖子，你可以參考參考。原帖地址：

參考：
如果你沒有安裝Berkeley db(8)庫軟體包，或不知是否擁有；你就需要在Makefile文件中去除對它的支持。編輯你的Makefile文件，查找以DBMDEF開始的行：

DBMDEF= -DNDBM –DNEWDB –DINS ?這一行

刪除這個部分

刪除字元串「-DNEWDB」這個部分後，修改完成後，結果如下所示：

DBMDEF= -DNDBM –DNIS ?刪除以後

接著查找以LIBS開始的行：

LIBS= -ldb -ldbm -lresolv?這一行(不完全准確)

刪除這個部分

刪除這行的字元串「-ldb」這個部分，修改完成後，結果如下所示：

LIBS= -ldbm -lresolv ?刪除以後

這樣就完成了從你的Makefile中刪除對Berkeley db的支持。

如果你的系統支持Berkeley db的話，則你還需要給Makefile一些消息。必須指定正確的頭文件和庫函數的路徑，以便將其包含到sendmail中去。查找以INCDIRS開始的行：

INCDIRS=-I/usr/sww/include ?這一行
# loader options
LDOPTS= -Bstatic
# Library directories
LIBDIRS=-L/usr/sww/lib ?還有這一行

你需要將這兩行中的路徑名改為Berkeley db的庫所在路徑。如果你無法確定，最好去除對Berkeley db的支持。

INCDIRS=-I/usr/local/include/db ?新的
# loader options
LDOPTS= -Bstatic
# Library directories
LIBDIRS=-L/usr/local/lib ?新的

上面這個修改的例子，是基於Berkeley db的頭文件在/usr/local/include/db，庫文件在/usr/local/lib目錄下所做的，可供參考。

希望以上內容對你有所幫助！

❺ 請教linux下如何實現原子自增操作

Linux的源碼中x86體系結構原子操作的定義文件為。
linux2.6/include/asm-i386/atomic.h
文件內定義了原子類型atomic_t，其僅有一個欄位counter，用於保存32位的數據。
typedef struct { volatile int counter; } atomic_t;
其中原子操作函數atomic_inc完成自加原子操作。
/**
* atomic_inc - increment atomic variable
* @v: pointer of type atomic_t
*
* Atomically increments @v by 1.
*/
static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__(
LOCK "incl %0"
:"=m" (v->counter)
:"m" (v->counter));
}
其中LOCK宏的定義為。
#ifdef CONFIG_SMP
#define LOCK "lock ; "
#else
#define LOCK ""
#endif
可見，在對稱多處理器架構的情況下，LOCK被解釋為指令前綴lock。而對於單處理器架構，LOCK不包含任何內容。

❻ 怎樣寫linux下的USB設備驅動程序

寫一個USB的驅動程序最 基本的要做四件事：驅動程序要支持的設備、注冊USB驅動程序、探測和斷開、提交和控制urb（USB請求塊）
驅動程序支持的設備：有一個結構體struct usb_device_id，這個結構體提供了一列不同類型的該驅動程序支持的USB設備，對於一個只控制一個特定的USB設備的驅動程序來說，struct usb_device_id表被定義為：
/* 驅動程序支持的設備列表 */
static struct usb_device_id skel_table [] = {
{ USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID) },
{ } /* 終止入口 */
};
MODULE_DEVICE_TABLE (usb, skel_table);
對 於PC驅動程序，MODULE_DEVICE_TABLE是必需的，而且usb必需為該宏的第一個值，而USB_SKEL_VENDOR_ID和 USB_SKEL_PRODUCT_ID就是這個特殊設備的製造商和產品的ID了，我們在程序中把定義的值改為我們這款USB的，如：
/* 定義製造商和產品的ID號 */
#define USB_SKEL_VENDOR_ID 0x1234
#define USB_SKEL_PRODUCT_ID 0x2345
這兩個值可以通過命令lsusb，當然你得先把USB設備先插到主機上了。或者查看廠商的USB設備的手冊也能得到，在我機器上運行lsusb是這樣的結果：
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 1234:2345 Abc Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
得到這兩個值後把它定義到程序里就可以了。
注冊USB驅動程序：所 有的USB驅動程序都必須創建的結構體是struct usb_driver。這個結構體必須由USB驅動程序來填寫，包括許多回調函數和變數，它們向USB核心代碼描述USB驅動程序。創建一個有效的 struct usb_driver結構體，只須要初始化五個欄位就可以了，在框架程序中是這樣的：
static struct usb_driver skel_driver = {
.owner = THIS_MODULE,
.name = "skeleton",
.probe = skel_probe,
.disconnect = skel_disconnect,
.id_table = skel_table,
};
探測和斷開：當 一個設備被安裝而USB核心認為該驅動程序應該處理時，探測函數被調用，探測函數檢查傳遞給它的設備信息，確定驅動程序是否真的適合該設備。當驅動程序因 為某種原因不應該控制設備時，斷開函數被調用，它可以做一些清理工作。探測回調函數中，USB驅動程序初始化任何可能用於控制USB設備的局部結構體，它 還把所需的任何設備相關信息保存到一個局部結構體中，
提交和控制urb：當驅動程序有數據要發送到USB設備時（大多數情況是在驅動程序的寫函數中），要分配一個urb來把數據傳輸給設備：
/* 創建一個urb,並且給它分配一個緩存*/
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
retval = -ENOMEM;
goto error;
}
當urb被成功分配後，還要創建一個DMA緩沖區來以高效的方式發送數據到設備，傳遞給驅動程序的數據要復制到這塊緩沖中去：
buf = usb_buffer_alloc(dev->udev, count, GFP_KERNEL, &urb->transfer_dma);
if (!buf) {
retval = -ENOMEM;
goto error;
}

if (_from_user(buf, user_buffer, count)) {
retval = -EFAULT;
goto error;
}
當數據從用戶空間正確復制到局部緩沖區後，urb必須在可以被提交給USB核心之前被正確初始化：
/* 初始化urb */
usb_fill_bulk_urb(urb, dev->udev,
usb_sndbulkpipe(dev->udev, dev->bulk_out_endpointAddr),
buf, count, skel_write_bulk_callback, dev);
urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
然後urb就可以被提交給USB核心以傳輸到設備了：
/* 把數據從批量OUT埠發出 */
retval = usb_submit_urb(urb, GFP_KERNEL);
if (retval) {
err("%s - failed submitting write urb, error %d", __FUNCTION__, retval);
goto error;
}
當urb被成功傳輸到USB設備之後，urb回調函數將被USB核心調用，在我們的例子中，我們初始化urb，使它指向skel_write_bulk_callback函數，以下就是該函數：
static void skel_write_bulk_callback(struct urb *urb, struct pt_regs *regs)
{
struct usb_skel *dev;

dev = (struct usb_skel *)urb->context;

if (urb->status &&
!(urb->status == -ENOENT ||
urb->status == -ECONNRESET ||
urb->status == -ESHUTDOWN)) {
dbg("%s - nonzero write bulk status received: %d",
__FUNCTION__, urb->status);
}

/* 釋放已分配的緩沖區 */
usb_buffer_free(urb->dev, urb->transfer_buffer_length,
urb->transfer_buffer, urb->transfer_dma);
}
有時候USB驅動程序只是要發送或者接收一些簡單的數據，驅動程序也可以不用urb來進行數據的傳輸，這是里涉及到兩個簡單的介面函數：usb_bulk_msg和usb_control_msg ，在這個USB框架程序里讀操作就是這樣的一個應用：
/* 進行阻塞的批量讀以從設備獲取數據 */
retval = usb_bulk_msg(dev->udev,
usb_rcvbulkpipe(dev->udev, dev->bulk_in_endpointAddr),
dev->bulk_in_buffer,
min(dev->bulk_in_size, count),
&count, HZ*10);

/*如果讀成功，復制到用戶空間 */
if (!retval) {
if (_to_user(buffer, dev->bulk_in_buffer, count))
retval = -EFAULT;
else
retval = count;
}
usb_bulk_msg介面函數的定義如下：
int usb_bulk_msg(struct usb_device *usb_dev,unsigned int pipe,
void *data,int len,int *actual_length,int timeout);
其參數為：
struct usb_device *usb_dev：指向批量消息所發送的目標USB設備指針。
unsigned int pipe：批量消息所發送目標USB設備的特定端點，此值是調用usb_sndbulkpipe或者usb_rcvbulkpipe來創建的。
void *data：如果是一個OUT端點，它是指向即將發送到設備的數據的指針。如果是IN端點，它是指向從設備讀取的數據應該存放的位置的指針。
int len：data參數所指緩沖區的大小。
int *actual_length：指向保存實際傳輸位元組數的位置的指針，至於是傳輸到設備還是從設備接收取決於端點的方向。
int timeout：以Jiffies為單位的等待的超時時間，如果該值為0，該函數一直等待消息的結束。
如果該介面函數調用成功，返回值為0，否則返回一個負的錯誤值。
usb_control_msg介面函數定義如下：
int usb_control_msg(struct usb_device *dev,unsigned int pipe,__u8 request,__u8requesttype,__u16 value,__u16 index,void *data,__u16 size,int timeout)
除了允許驅動程序發送和接收USB控制消息之外，usb_control_msg函數的運作和usb_bulk_msg函數類似，其參數和usb_bulk_msg的參數有幾個重要區別：
struct usb_device *dev：指向控制消息所發送的目標USB設備的指針。
unsigned int pipe：控制消息所發送的目標USB設備的特定端點，該值是調用usb_sndctrlpipe或usb_rcvctrlpipe來創建的。
__u8 request：控制消息的USB請求值。
__u8 requesttype：控制消息的USB請求類型值。
__u16 value：控制消息的USB消息值。
__u16 index：控制消息的USB消息索引值。
void *data：如果是一個OUT端點，它是指身即將發送到設備的數據的指針。如果是一個IN端點，它是指向從設備讀取的數據應該存放的位置的指針。
__u16 size：data參數所指緩沖區的大小。
int timeout：以Jiffies為單位的應該等待的超時時間，如果為0，該函數將一直等待消息結束。
如果該介面函數調用成功，返回傳輸到設備或者從設備讀取的位元組數；如果不成功它返回一個負的錯誤值。
這兩個介面函數都不能在一個中斷上下文中或者持有自旋鎖的情況下調用，同樣，該函數也不能被任何其它函數取消，使用時要謹慎。
我們要給未知的USB設備寫驅動程序，只需要把這個框架程序稍做修改就可以用了，前面我們已經說過要修改製造商和產品的ID號，把0xfff0這兩個值改為未知USB的ID號。
#define USB_SKEL_VENDOR_ID 0xfff0
#define USB_SKEL_PRODUCT_ID 0xfff0
還 有就是在探測函數中把需要探測的介面端點類型寫好，在這個框架程序中只探測了批量（USB_ENDPOINT_XFER_BULK）IN和OUT端點，可 以在此處使用掩碼（USB_ENDPOINT_XFERTYPE_MASK）讓其探測其它的端點類型，驅動程序會對USB設備的每一個介面進行一次探測， 當探測成功後，驅動程序就被綁定到這個介面上。再有就是urb的初始化問題，如果你只寫簡單的USB驅動，這塊不用多加考慮，框架程序里的東西已經夠用 了，這里我們簡單介紹三個初始化urb的輔助函數：
usb_fill_int_urb ：它的函數原型是這樣的：
void usb_fill_int_urb(struct urb *urb,struct usb_device *dev,
unsigned int pipe,void *transfer_buff,
int buffer_length,usb_complete_t complete,
void *context,int interval);
這個函數用來正確的初始化即將被發送到USB設備的中斷端點的urb。
usb_fill_bulk_urb ：它的函數原型是這樣的：
void usb_fill_bulk_urb(struct urb *urb,struct usb_device *dev,
unsigned int pipe,void *transfer_buffer,
int buffer_length,usb_complete_t complete)
這個函數是用來正確的初始化批量urb端點的。
usb_fill_control_urb ：它的函數原型是這樣的：
void usb_fill_control_urb(struct urb *urb,struct usb_device *dev,unsigned int pipe,unsigned char *setup_packet,void *transfer_buffer,int buffer_length,usb_complete_t complete,void *context);
這個函數是用來正確初始化控制urb端點的。
還有一個初始化等時urb的，它現在還沒有初始化函數，所以它們在被提交到USB核心前，必須在驅動程序中手工地進行初始化，可以參考內核源代碼樹下的/usr/src/~/drivers/usb/media下的konicawc.c文件。

❼ Linux 虛擬地址空間如何分布

一個進程的虛擬地址空間主要由兩個數據結來描述。一個是最高層次的：mm_struct，一個是較高層次的：vm_area_structs。最高層次的mm_struct結構描述了一個進程的整個虛擬地址空間。較高層次的結構vm_area_truct描述了虛擬地址空間的一個區間（簡稱虛擬區）。

1. MM_STRUCT結構

mm_strcut 用來描述一個進程的虛擬地址空間，在/include/linux/sched.h 中描述如下：

struct mm_struct {

struct vm_area_struct * mmap; /* 指向虛擬區間（VMA）鏈表 */

rb_root_t mm_rb; ／*指向red_black樹*/

struct vm_area_struct * mmap_cache; /* 指向最近找到的虛擬區間*/

pgd_t * pgd; ／*指向進程的頁目錄*/

atomic_t mm_users; /* 用戶空間中的有多少用戶*/

atomic_t mm_count; /* 對"struct mm_struct"有多少引用*/

int map_count; /* 虛擬區間的個數*/

struct rw_semaphore mmap_sem;

spinlock_t page_table_lock; /* 保護任務頁表和 mm->rss */

struct list_head mmlist; /*所有活動（active）mm的鏈表 */

unsigned long start_code, end_code, start_data, end_data;

unsigned long start_brk, brk, start_stack;

unsigned long arg_start, arg_end, env_start, env_end;

unsigned long rss, total_vm, locked_vm;

unsigned long def_flags;

unsigned long cpu_vm_mask;

unsigned long swap_address;

unsigned mpable:1;

/* Architecture-specific MM context */

mm_context_t context;

};

對該結構進一步說明如下：

在內核代碼中，指向這個數據結構的變數常常是mm。

每個進程只有一個mm_struct結構，在每個進程的task_struct結構中，有一個指向該進程的結構。可以說，mm_struct結構是對整個用戶空間的描述。

一個進程的虛擬空間中可能有多個虛擬區間（參見下面對vm_area_struct描述），對這些虛擬區間的組織方式有兩種，當虛擬區較少時採用單鏈表，由mmap指針指向這個鏈表，當虛擬區間多時採用「紅黑樹（red_black
tree）」結構，由mm_rb指向這顆樹。在2.4.10以前的版本中，採用的是AVL樹，因為與AVL樹相比，對紅黑樹進行操作的效率更高。

因為程序中用到的地址常常具有局部性，因此，最近一次用到的虛擬區間很可能下一次還要用到，因此，把最近用到的虛擬區間結構應當放入高速緩存，這個虛擬區間就由mmap_cache指向。

指針pgt指向該進程的頁目錄（每個進程都有自己的頁目錄，注意同內核頁目錄的區別）,當調度程序調度一個程序運行時，就將這個地址轉成物理地址，並寫入控制寄存器（CR3）。

由於進程的虛擬空間及其下屬的虛擬區間有可能在不同的上下文中受到訪問，而這些訪問又必須互斥，所以在該結構中設置了用於P、V操作的信號量mmap_sem。此外，page_table_lock也是為類似的目的而設置。

雖然每個進程只有一個虛擬地址空間，但這個地址空間可以被別的進程來共享，如，子進程共享父進程的地址空間（也即共享mm_struct結構）。所以，用mm_user和mm_count進行計數。類型atomic_t實際上就是整數，但對這種整數的操作必須是「原子」的。

另外，還描述了代碼段、數據段、堆棧段、參數段以及環境段的起始地址和結束地址。這里的段是對程序的邏輯劃分，與我們前面所描述的段機制是不同的。

mm_context_t是與平台相關的一個結構，對i386 幾乎用處不大。

在後面對代碼的分析中對有些域給予進一步說明。

2. VM_AREA_STRUCT 結構

vm_area_struct描述進程的一個虛擬地址區間，在/include/linux/mm.h中描述如下：

struct vm_area_struct

struct mm_struct * vm_mm; /* 虛擬區間所在的地址空間*/

unsigned long vm_start; /* 在vm_mm中的起始地址*/

unsigned long vm_end; /*在vm_mm中的結束地址 */

/* linked list of VM areas per task, sorted by address */

struct vm_area_struct *vm_next;

pgprot_t vm_page_prot; /* 對這個虛擬區間的存取許可權 */

unsigned long vm_flags; /* 虛擬區間的標志. */

rb_node_t vm_rb;

/*

* For areas with an address space and backing store,

* one of the address_space->i_mmap{,shared} lists,

* for shm areas, the list of attaches, otherwise unused.

*/

struct vm_area_struct *vm_next_share;

struct vm_area_struct **vm_pprev_share;

/*對這個區間進行操作的函數 */

struct vm_operations_struct * vm_ops;

/* Information about our backing store: */

unsigned long vm_pgoff; /* Offset (within vm_file) in PAGE_SIZE

units, *not* PAGE_CACHE_SIZE */

struct file * vm_file; /* File we map to (can be NULL). */

unsigned long vm_raend; /* XXX: put full readahead info here. */

void * vm_private_data; /* was vm_pte (shared mem) */

};

vm_flag是描述對虛擬區間的操作的標志，其定義和描述如下

標志名 描述

VM_DENYWRITE 在這個區間映射一個打開後不能用來寫的文件。

VM_EXEC 頁可以被執行。

VM_EXECUTABLE 頁含有可執行代碼。

VM_GROWSDOWN 這個區間可以向低地址擴展。

VM_GROWSUP 這個區間可以向高地址擴展。

VM_IO 這個區間映射一個設備的I/O地址空間。

VM_LOCKED 頁被鎖住不能被交換出去。

VM_MAYEXEC VM_EXEC 標志可以被設置。

VM_MAYREAD VM_READ 標志可以被設置。

VM_MAYSHARE VM_SHARE 標志可以被設置。

VM_MAYWRITE VM_WRITE 標志可以被設置。

VM_READ 頁是可讀的。

VM_SHARED 頁可以被多個進程共享。

VM_SHM 頁用於IPC共享內存。
VM_WRITE 頁是可寫的。

較高層次的結構vm_area_structs是由雙向鏈表連接起來的，它們是按虛地址的降順序來排列的，每個這樣的結構都對應描述一個相鄰的地址空間范圍。之所以這樣分割，是因為每個虛擬區間可能來源不同，有的可能來自可執行映象，有的可能來自共享庫，而有的則可能是動態分配的內存區，所以對每一個由vm_area_structs結構所描述的區間的處理操作和它前後范圍的處理操作不同。因此Linux
把虛擬內存分割管理，並利用了虛擬內存處理常式（vm_ops）來抽象對不同來源虛擬內存的處理方法。不同的虛擬區間其處理操作可能不同，Linux在這里利用了面向對象的思想，即把一個虛擬區間看成一個對象，用vm_area_structs描述了這個對象的屬性，其中的vm_operation結構描述了在這個對象上的操作，其定義在／include／linux／mm.h中：

/*

* These are the virtual MM functions - opening of an area, closing and

* unmapping it (needed to keep files on disk up-to-date etc), pointer

* to the functions called when a no-page or a wp-page exception occurs.

*/

struct vm_operations_struct {

void (*open)(struct vm_area_struct * area);

void (*close)(struct vm_area_struct * area);

struct page * (*nopage)(struct vm_area_struct * area, unsigned long address, int unused);

};

vm_operations結構中包含的是函數指針；其中，open、close分別用於虛擬區間的打開、關閉，而nopage用於當虛存頁面不在物理內存而引起的「缺頁異常」時所應該調用的函數。

3．紅黑樹結構

Linux內核從2.4.10開始，對虛擬區的組織不再採用AVL樹，而是採用紅黑樹，這也是出於效率的考慮，雖然AVL樹和紅黑樹很類似，但在插入和刪除節點方面，採用紅黑樹的性能更好一些，下面對紅黑樹給予簡單介紹。
一顆紅黑樹是具有以下特點的二叉樹：
每個節點著有顏色，或者為紅，或者為黑
根節點為黑色
如果一個節點為紅色，那麼它的子節點必須為黑色
從一個節點到葉子節點上的所有路徑都包含有相同的黑色節點數

❽ 新手求教LINUX下的原子操作該怎麼寫

linux中關於原子操作

2016年08月02日

原子操作:就是在執行某一操作時不被打斷。

linux原子操作問題來源於中斷、進程的搶占以及多核smp系統中程序的並發執行。

對於臨界區的操作可以加鎖來保證原子性，對於全局變數或靜態變數操作則需要依賴於硬體平台的原子變數操作。

因此原子操作有兩類：一類是各種臨界區的鎖，一類是操作原子變數的函數。

對於arm來說，單條匯編指令都是原子的，多核smp也是，因為有匯流排仲裁所以cpu可以單獨佔用匯流排直到指令結束，多核系統中的原子操作通常使用內存柵障（memory barrier）來實現，即一個CPU核在執行原子操作時，其他CPU核必須停止對內存操作或者不對指定的內存進行操作，這樣才能避免數據競爭問題。但是對於load update store這個過程可能被中斷、搶占，所以arm指令集有增加了ldrex/strex這樣的實現load update store的原子指令。

但是linux種對於c/c++程序（一條c編譯成多條匯編），由於上述提到的原因不能保證原子性，因此linux提供了一套函數來操作全局變數或靜態變數。

• 一.整型原子操作定義於#include<asm/atomic.h>分為 定義，獲取，加減，測試，返回。void atomic_set(atomic_t *v,int i); //設置原子變數v的值為iatomic_t v = ATOMIC_INIT(0); //定義原子變數v,並初始化為0;atomic_read(atomic_t* v); //返回原子變數v的值;void atomic_add(int i, atomic_t* v); //原子變數v增加i;void atomic_sub(int i, atomic_t* v); void atomic_inc(atomic_t* v); //原子變數增加1;void atomic_dec(atomic_t* v);int atomic_inc_and_test(atomic_t* v); //先自增1,然後測試其值是否為0,若為0,則返回true,否則返回false;int atomic_dec_and_test(atomic_t* v); int atomic_sub_and_test(int i, atomic_t* v); //先減i,然後測試其值是否為0,若為0,則返回true,否則返回false;注意：只有自加，沒有加操作int atomic_add_return(int i, atomic_t* v); //v的值加i後返回新的值;int atomic_sub_return(int i, atomic_t* v); int atomic_inc_return(atomic_t* v); //v的值自增1後返回新的值;int atomic_dec_return(atomic_t* v);二.位原子操作定義於#include<asm/bitops.h>分為 設置，清除，改變，測試void set_bit(int nr, volatile void* addr); //設置地址addr的第nr位,所謂設置位,就是把位寫為1;void clear_bit(int nr, volatile void* addr); //清除地址addr的第nr位,所謂清除位,就是把位寫為0;void change_bit(int nr, volatile void* addr); //把地址addr的第nr位反轉;int test_bit(int nr, volatile void* addr); //返回地址addr的第nr位;int test_and_set_bit(int nr, volatile void* addr);//測試並設置位;若addr的第nr位非0,則返回true; 若addr的第nr位為0,則返回false;int test_and_clear_bit(int nr, volatile void* addr);//測試並清除位;int test_and_change_bit(int nr, volatile void* addr);//測試並反轉位;上述操作等同於先執行test_bit(nr,voidaddr)然後在執行xxx_bit(nr,voidaddr)


• 舉個簡單例子：為了實現設備只能被一個進程打開，從而避免競態的出現static atomic_t scull_available = ATOMIC_INIT(1);//init atomic在scull_open 函數和scull_close函數中：int scull_open(struct inode *inode, struct file *filp){ struct scull_dev *dev; // device information dev = container_of(inode->i_cdev, struct scull_dev, cdev); filp->private_data = dev;// for other methods if(!atomic_dec_and_test(&scull_available)){ atomic_inc(&scull_available); return -EBUSY; } return 0; // success}int scull_release(struct inode *inode, struct file *filp){ atomic_inc(&scull_available); return 0;}



假設原子變數的底層實現是由一個匯編指令實現的，這個原子性必然有保障。但是如果原子變數的實現是由多條指令組合而成的，那麼對於SMP和中斷的介入會不會有什麼影響呢？我在看ARM的原子變數操作實現的時候，發現其是由多條匯編指令（ldrex/strex）實現的。在參考了別的書籍和資料後，發現大部分書中對這兩條指令的描訴都是說他們是支持在SMP系統中實現多核共享內存的互斥訪問。但在UP系統中使用，如果ldrex/strex和之間發生了中斷，並在中斷中也用ldrex/strex操作了同一個原子變數會不會有問題呢？就這個問題，我認真看了一下內核的ARM原子變數源碼和ARM官方對於ldrex/strex的功能解釋，總結如下：

一、ARM構架的原子變數實現結構

對於ARM構架的原子變數實現源碼位於：arch/arm/include/asm/atomic.h

其主要的實現代碼分為ARMv6以上（含v6）構架的實現和ARMv6版本以下的實現。

該文件的主要結構如下：


• #if__LINUX_ARM_ARCH__>=6

• ......(通過ldrex/strex指令的匯編實現)

• #else/*ARM_ARCH_6*/
  

• #ifdef CONFIG_SMP

• #errorSMPnotsupportedonpre-ARMv6 CPUs

• #endif
  

• ......(通過關閉CPU中斷的C語言實現)
  

• #endif/*__LINUX_ARM_ARCH__*/

• ......

• #ifndef CONFIG_GENERIC_ATOMIC64
  

• ......(通過ldrexd/strexd指令的匯編實現的64bit原子變數的訪問)
  

• #else/*!CONFIG_GENERIC_ATOMIC64*/
  

• #include<asm-generic/atomic64.h>
  

• #endif
  

• #include<asm-generic/atomic-long.h>

這樣的安排是依據ARM核心指令集版本的實現來做的：

（1）在ARMv6以上（含v6）構架有了多核的CPU，為了在多核之間同步數據和控制並發，ARM在內存訪問上增加了獨占監測（Exclusive monitors）機制（一種簡單的狀態機），並增加了相關的ldrex/strex指令。請先閱讀以下參考資料（關鍵在於理解local monitor和Global monitor）：

1.2.2.Exclusive monitors

4.2.12.LDREX和STREX

（2）對於ARMv6以前的構架不可能有多核CPU，所以對於變數的原子訪問只需要關閉本CPU中斷即可保證原子性。

對於（2），非常好理解。

但是（1）情況，我還是要通過源碼的分析才認同這種代碼，以下我僅僅分析最具有代表性的atomic_add源碼，其他的API原理都一樣。如果讀者還不熟悉C內嵌匯編的格式，請參考《ARM GCC內嵌匯編手冊》

二、內核對於ARM構架的atomic_add源碼分析

• /*

• *ARMv6 UP 和 SMP 安全原子操作。 我們是用獨占載入和

• *獨占存儲來保證這些操作的原子性。我們可能會通過循環

• *來保證成功更新變數。

• */
  

• static inline void atomic_add(inti,atomic_t*v)

• {

• unsigned long tmp;

• intresult;

• __asm__ __volatile__("@ atomic_add "

• "1: ldrex %0, [%3] "

• " add %0, %0, %4 "

• " strex %1, %0, [%3] "

• " teq %1, #0 "

• " bne 1b"

• :"=&r"(result),"=&r"(tmp),"+Qo"(v->counter)

• :"r"(&v->counter),"Ir"(i)

• :"cc");

• }

源碼分析：

注意：根據內聯匯編的語法，result、tmp、&v->counter對應的數據都放在了寄存器中操作。如果出現上下文切換，切換機制會做寄存器上下文保護。

（1）ldrex %0, [%3]

意思是將&v->counter指向的數據放入result中，並且（分別在Local monitor和Global monitor中）設置獨占標志。

（2）add %0, %0, %4

result = result + i

（3）strex %1, %0, [%3]

意思是將result保存到&v->counter指向的內存中，此時Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。

（4）teq %1, #0

測試strex是否成功（tmp == 0？？）

（5）bne 1b

如果發現strex失敗，從（1）再次執行。

通過上面的分析，可知關鍵在於strex的操作是否成功的判斷上。而這個就歸功於ARM的Exclusive monitors和ldrex/strex指令的機制。以下通過可能的情況分析ldrex/strex指令機制。（請閱讀時參考4.2.12.LDREX和STREX）

1、UP系統或SMP系統中變數為非CPU間共享訪問的情況

此情況下，僅有一個CPU可能訪問變數，此時僅有Local monitor需要關注。

假設CPU執行到（2）的時候，來了一個中斷，並在中斷里使用ldrex/strex操作了同一個原子變數。則情況如下圖所示：



雖然對於人來說，這種情況比較BT。但是在飛速運行的CPU來說，BT的事情隨時都可能發生。

• A：將該物理地址標記為CPU0獨占訪問，並清除CPU0對其他任何物理地址的任何獨占訪問標記。

• B：標記此物理地址為CPU1獨占訪問，並清除CPU1對其他任何物理地址的任何獨占訪問標記。

• C：再次標記此物理地址為CPU0獨占訪問，並清除CPU0對其他任何物理地址的任何獨占訪問標記。

• D：已被標記為CPU0獨占訪問，進行存儲並清除獨占訪問標記，並返回0（操作成功）。

• E：沒有標記為CPU1獨占訪問，不會進行存儲，並返回1（操作失敗）。

• F：沒有標記為CPU0獨占訪問，不會進行存儲，並返回1（操作失敗）。

當然還有其他許多復雜的可能，也可以通過ldrex/strex指令的機制分析出來。從上面列舉的分析中，我們可以看出：ldrex/strex可以保證在任何情況下（包括被中斷）的訪問原子性。所以內核中ARM構架中的原子操作是可以信任的。

❾ linux內核模塊編寫要求從一個虛存區VMA和一個虛地址addr求這個地址所在的物理頁面

implicit declaration of function ***
查查英語也應該曉得了阿....

隱式的函數聲明，就是說你使用了kmap_atomic、kmap_atomic但是沒有聲明，一般是因為沒有包含頭文件，或者是內核的API發生了些許變化。

這兩個函數包含在linux/highmem.h中，你在程序中添加一句：#include <linux/highmem.h>試試。
PS ：這個是在2.6.38的內核中的，你在lxr.linux.no搜下對應版本的kernel，我沒有細細查。