linux驅動介面

⑴ linux驅動開發中申請內存的介面有哪些

vmalloc、kmalloc、kzalloc之類的吧，我也不太清楚正在學習，僅供參考。

⑵ linux驅動程序已有，怎麼利用介面函數編寫程

Linux的最大的好處之一就是它的源碼公開。同時，公開的核心源碼也吸引著無數的電腦愛好者和程序員；他們把解讀和分析Linux的核心源碼作為自己的最大興趣，把修改Linux源碼和改造Linux系統作為自己對計算機技術追求的最大目標。 Linux內核源碼是很具吸引力的，特別是當你弄懂了一個分析了好久都沒搞懂的問題；或者是被你修改過了的內核，順利通過編譯，一切運行正常的時候。那種成就感真是油然而生！而且，對內核的分析，除了出自對技術的狂熱追求之外，這種令人生畏的勞動所帶來的回報也是非常令人著迷的，這也正是它擁有眾多追隨者的主要原因： 首先，你可以從中學到很多的計算機的底層知識，如後面將講到的系統的引導和硬體提供的中斷機制等；其它，象虛擬存儲的實現機制，多任務機制，系統保護機制等等，這些都是非都源碼不能體會的。 同時，你還將從操作系統的整體結構中，體會整體設計在軟體設計中的份量和作用，以及一些宏觀設計的方法和技巧：Linux的內核為上層應用提供一個與具體硬體不相關的平台；同時在內核內部，它又把代碼分為與體系結構和硬體相關的部分，和可移植的部分；再例如，Linux雖然不是微內核的，但他把大部分的設備驅動處理成相對獨立的內核模塊，這樣減小了內核運行的開銷，增強了內核代碼的模塊獨立性。 而且你還能從對內核源碼的分析中，體會到它在解決某個具體細節問題時，方法的巧妙：如後面將分析到了的Linux通過Botoom_half機制來加快系統對中斷的處理。 最重要的是：在源碼的分析過程中，你將會被一點一點地、潛移默化地專業化。一個專業的程序員，總是把代碼的清晰性，兼容性，可移植性放在很重要的位置。他們總是通過定義大量的宏，來增強代碼的清晰度和可讀性，而又不增加編譯後的代碼長度和代碼的運行效率；他們總是在編碼的同時，就考慮到了以後的代碼維護和升級。 甚至，只要分析百分之一的代碼後，你就會深刻地體會到，什麼樣的代碼才是一個專業的程序員寫的，什麼樣的代碼是一個業余愛好者寫的。而這一點是任何沒有真正分析過標准代碼的人都無法體會到的。 然而，由於內核代碼的冗長，和內核體系結構的龐雜，所以分析內核也是一個很艱難，很需要毅力的事；在缺乏指導和交流的情況下，尤其如此。只有方法正確，才能事半功倍。正是基於這種考慮，作者希望通過此文能給大家一些借鑒和啟迪。 由於本人所進行的分析都是基於2.2.5版本的內核；所以，如果沒有特別說明，以下分析都是基於i386單處理器的2.2.5版本的Linux內核。所有源文件均是相對於目錄/usr/src/linux的。 方法之一：從何入手 要分析Linux內核源碼，首先必須找到各個模塊的位置，也即要弄懂源碼的文件組織形式。雖然對於有經驗的高手而言，這個不是很難；但對於很多初級的Linux愛好者，和那些對源碼分析很有興趣但接觸不多的人來說，這還是很有必要的。 1、Linux核心源程序通常都安裝在/usr/src/linux下，而且它有一個非常簡單的編號約定：任何偶數的核心（的二個數為偶數，例如2.0.30）都是一個穩定地發行的核心，而任何奇數的核心（例如2.1.42）都是一個開發中的核心。 2、核心源程序的文件按樹形結構進行組織，在源程序樹的最上層，即目錄/usr/src/linux下有這樣一些目錄和文件： ◆ COPYING: GPL版權申明。對具有GPL版權的源代碼改動而形成的程序，或使用GPL工具產生的程序，具有使用GPL發表的義務，如公開源代碼； ◆ CREDITS: 光榮榜。對Linux做出過很大貢獻的一些人的信息； ◆ MAINTAINERS: 維護人員列表，對當前版本的內核各部分都有誰負責； ◆ Makefile: 第一個Makefile文件。用來組織內核的各模塊，記錄了個模塊間的相互這間的聯系和依託關系，編譯時使用；仔細閱讀各子目錄下的Makefile文件對弄清各個文件這間的聯系和依託關系很有幫助； ◆ ReadMe: 核心及其編譯配置方法簡單介紹； ◆ Rules.make: 各種Makefilemake所使用的一些共同規則； ◆ REPORTING-BUGS:有關報告Bug 的一些內容； ● Arch/ ：arch子目錄包括了所有和體系結構相關的核心代碼。它的每一個子目錄都代表一種支持的體系結構，例如i386就是關於intel cpu及與之相兼容體系結構的子目錄。PC機一般都基於此目錄； ● Include/: include子目錄包括編譯核心所需要的大部分頭文件。與平台無關的頭文件在 include/linux子目錄下，與 intel cpu相關的頭文件在include/asm-i386子目錄下,而include/scsi目錄則是有關scsi設備的頭文件目錄； ● Init/： 這個目錄包含核心的初始化代碼(註：不是系統的引導代碼)，包含兩個文件main.c和Version.c，這是研究核心如何工作的好的起點之一。 ● Mm/：這個目錄包括所有獨立於 cpu 體系結構的內存管理代碼，如頁式存儲管理內存的分配和釋放等；而和體系結構相關的內存管理代碼則位於arch/*/mm/，例如arch/i386/mm/Fault.c； ● Kernel/：主要的核心代碼，此目錄下的文件實現了大多數linux系統的內核函數，其中最重要的文件當屬sched.c；同樣，和體系結構相關的代碼在arch/*/kernel中； ● Drivers/： 放置系統所有的設備驅動程序；每種驅動程序又各佔用一個子目錄：如，/block 下為塊設備驅動程序，比如ide（ide.c）。如果你希望查看所有可能包含文件系統的設備是如何初始化的，你可以看drivers/block/genhd.c中的device_setup()。它不僅初始化硬碟，也初始化網路，因為安裝nfs文件系統的時候需要網路； ● Documentation/: 文檔目錄,沒有內核代碼，只是一套有用的文檔，可惜都是English的，看看應該有用的哦； ● Fs/: 所有的文件系統代碼和各種類型的文件操作代碼，它的每一個子目錄支持一個文件系統, 例如fat和ext2； ● Ipc/: 這個目錄包含核心的進程間通訊的代碼； ● Lib/: 放置核心的庫代碼； ● Net/: 核心與網路相關的代碼； ● Moles/: 模塊文件目錄，是個空目錄，用於存放編譯時產生的模塊目標文件； ● Scripts/: 描述文件，腳本，用於對核心的配置； 一般，在每個子目錄下，都有一個 Makefile 和一個Readme 文件，仔細閱讀這兩個文件，對內核源碼的理解很有用。 對Linux內核源碼的分析，有幾個很好的入口點：一個就是系統的引導和初始化，即從機器加電到系統核心的運行；另外一個就是系統調用，系統調用是用戶程序或操作調用核心所提供的功能的介面。對於那些對硬體比較熟悉的愛好者，從系統的引導入手進行分析，可能來的容易一些；而從系統調用下口，則可能更合適於那些在dos或Uinx、Linux下有過C編程經驗的高手。

⑶ 嵌入式Linux中如何實現應用程序與驅動程序函數介面問題，以GPIO為例

嵌入式Linux中如何實現應用程序與驅動程序函數介面問題，以GPIO為例
驅動中的函數定義：
static int sbc2440_leds_ioctl(
struct inode *inode,
struct file *file,
unsigned int cmd,
unsigned long arg)
{
switch(cmd) {
case 0:
case 1:
if (arg > 4) {
return -EINVAL;
}
s3c2410_gpio_setpin(led_table[arg], !cmd);
return 0;
default:
return -EINVAL;
}
}

應用程序中的函數定義：
ioctl(fd, on, led_no);
不明白的地方是函數名都不一樣，應用程序中的ioctl函數是如何將參數傳遞到驅動程序sbc2440_leds_ioctl中的？
xicain

⑷ Linux輸入設備驅動

輸入設備（如按鍵、鍵盤、觸摸屏、滑鼠等）是典型的字元設備，其一般的工作機理是底層在按鍵、觸摸等動作發送時產生一個中斷（或驅動通過Timer定時查詢)，然後CPU通過SPI、I-C或外部存儲器匯流排讀取鍵值、坐標等數據，並將它們放入一個緩沖區，字元設備驅動管理該緩沖區，而驅動的read ()介面讓用戶可以讀取鍵值、坐標等數據。顯然，在這些工作中，只是中斷、讀鍵值/坐標值是與設備相關的，而輸入事件的緩沖區管理以及字元設備驅動的file operations介面則對輸入設備是通用的。基於此，內核設計了輸入子系統，由核心層處理公共的工作。drivers/input/keyboardgpio_keys.c基於input架構實現了一個通用的GPIO按鍵驅動。該驅動是基於platform_driver架構的，名為「gpio-keys」。它將與硬體相關的信息(如使用的GPIO號，按下和抬起時的電平等）屏蔽在板文件platform_device的platform_data中，因此該驅動可應用於各個處理器，具有良好的跨平台性。GPIO按鍵驅動通過input_event () 、input_sync()這樣的函數來匯報按鍵事件以及同步事件。從底層的GPIO按鍵驅動可以看出，該驅動中沒有任何file_operations的動作，也沒有各種IO模型，注冊進入系統也用的是input_register_device (）這樣的與input相關的API。這是由於與Linux VFS介面的這一部分代碼全部都在drivers/input/evdev.c中實現了。

⑸ linux下如何開發sdio設備驅動

以LinuxKernelSdioMx28 / LinuxKernelSdioMx53項目代碼為例：

- mole_init(DibBridgeTargetMoleInit)
驅動模塊初始化入口

- DibBridgeTargetMoleInit()：模塊初始化函數。
1.調用sdio_register_driver()注冊sdio介面驅動，
2.調用register_chrdev()注冊驅動模塊為字元設備。

- sdio_register_driver()：向系統注冊sdio介面驅動，調用以後，系統會觸發sdio設備id檢測，如果設備id和介面驅動里.id_table里定義的id一致，則系統調用probe函數。
1. 可以在DibBridgeTargetMoleInit()里調用，這樣insmod之後，驅動介面即被注冊（設備id被注冊），有相應設備插入則probe會被調用（此種做法參考LinuxKernelSdioMx28）
2. 也可以在sdio初始化時調用，這樣設備插入時，probe不會被調用，只有在sdio初始化，sdio_register_driver()被調用時，系統才會重新檢測設備id，並調用probe。（此種做法好處是，模塊初始化不涉及何種設備，具有更好的通用性。參考LinuxKernelSdioMx53）

- static struct sdio_driver Dib_sdio_driver
是sdio介面驅動的結構體,包括.id_table, .probe()函數等，如下
static struct sdio_driver Dib_sdio_driver = {
.name = "Dib_sdio",
.id_table = Dib_sdio_ids,
.probe = Dib_sdio_probe,
.remove = __devexit_p(Dib_sdio_remove),
};
其中.id_table很重要，它裡面定義了此sdio驅動模塊關心的sdio設備id號，只有插入的sdio設備的id號和這裡面定義的id對應上，系統才會調用.probe函數。

- register_chrdev()
將驅動模塊向系統注冊為字元設備，並將操作該設備的介面函數file_operations也一起注冊了。
1.可以在DibBridgeTargetMoleInit()里調用。（參考LinuxKernelSdioMx53/LinuxKernelSdioMx28代碼）
2.也可以在probe函數里調用，即只有在系統檢測到硬體設備時才去注冊字元設備（參考sdk8remote代碼）

- struct file_operations
包含如下最基本的文件操作函數，
struct file_operations fops =
{
.ioctl = DibBridgeTargetMoleIoctl, //控制命令傳輸或數據傳輸
.open = DibBridgeTargetMoleOpen,
.read = DibBridgeTargetMoleReadData, //數據傳輸
.write = DibBridgeTargetMoleWriteData
.release = DibBridgeTargetMoleRelease,
};

- .ioctl/.read 等等

user space和kernel space的傳輸通道，通過使用_from_user和_to_user這樣的函數來實現數據傳遞
Linux方面的想相關知識可以網路搜索《Linux就該這么學》進行學習了解

⑹ Linux網路設備驅動的具體結構

Linux網路設備驅動程序的體系結構從上到下可以劃分為4層，依次為網路協議介面層、網路設備介面層、提供實際功能的設備驅動功能層以及網路設備與媒介層，這4層的作用如下所示：
1）網路協議介面層向網路層協議提供統一的數據包收發介面，不論上層協議是ARP，還是IP，都通過dev_queue_xmit() 函數發送數據，並通過netif rx ()函數接收數據。這一層的存在使得上層協議獨立於具體的設備。
2）網路設備介面層向協議介面層提供統一的用於描述具體網路設備屬性和操作的結構體net device,該結構體是設備驅動功能層中各函數的容器。實際上，網路設備介面層從宏觀上規劃了具體操作硬體的設備驅動功能層的結構。
3）設備驅動功能層的各函數是網路設備介面層net_device數據結構的具體成員，是驅使網路設備硬體完成相應動作的程序，它通過hard_start_ xmit ()函數啟動發送操作，並通過網路設備上的中斷觸發接收操作。
4）網路設備與媒介層是完成數據包發送和接收的物理實體，包括網路適配器和具體的傳輸媒介，網路適配器被設備驅動功能層中的函數在物理上驅動。對於Linux系統而言，網路設備和媒介都可以是虛擬的。

⑺ Linux設備驅動程序與外界的介面函數有哪些

驅動程序工作在內核空間，由內核來調用 比如某硬體的驅動程序中實現了hd_write()函數，則用戶在用戶空間打開這硬體的設備文件並調用系統調用函數write()時，內核就調用hd_write()函數。

⑻ Linux 網路設備介面層

Linux 網路設備驅動之網路協議介面層介紹。
網路協議介面層最主要的功能是給上層協議提供透明的數據包發送和接收介面。

⑼ Linux網路設備驅動的結構

Linux網路設備驅動程序的體系結構從上到下可以劃分為4層，依次為網路協議介面層、網路設備介面層、提供實際功能的設備驅動功能層以及網路設備與媒介層，這4層的作用如下所示。
1）網路協議介面層向網路層協議提供統一的數據包收發介面，不論上層協議是ARP，還是IP，都通過dev_queue_xmit() 函數發送數據，並通過netif rx ()函數接收數據。這一層的存在使得上層協議獨立於具體的設備。
2）網路設備介面層向協議介面層提供統一的用於描述具體網路設備屬性和操作的結構體net device,該結構體是設備驅動功能層中各函數的容器。實際上，網路設備介面層從宏觀上規劃了具體操作硬體的設備驅動功能層的結構。
3）設備驅動功能層的各函數是網路設備介面層net_device數據結構的具體成員，是驅使網路設備硬體完成相應動作的程序，它通過hard_start_ xmit ()函數啟動發送操作，並通過網路設備上的中斷觸發接收操作。
4）網路設備與媒介層是完成數據包發送和接收的物理實體，包括網路適配器和具體的傳輸媒介，網路適配器被設備驅動功能層中的函數在物理上驅動。對於Linux系統而言，網路設備和媒介都可以是虛擬的。

⑽ linux下應用層怎麼調用SD卡驅動介面

一般的驅動程序是不允許應用程序調用的，只有當驅動程序留出這種供外界訪問的介面才行，這種介面一般包括read，write，open，ioctl等介面，如果驅動中預留出了這些介面，就可以在應用程序中調用，比如fd=open(設備，參數);或者fd=ioctl(設備，參數);，這樣就會調用到這個設備驅動中的open或者ioctl函數。所以一般如果想再應用程序中調試某個驅動程序，常見的方法就是自己建立一個驅動模塊，這個模塊中預留出對外介面，比如ioctl。然後在你新建的這個驅動模塊中完成ioctl函數，如下：
int device_ioctl(fd,argv) {
/* your function; */
}
static struct file_operations device = {
.ioctl = device_ioctl //預留外部介面
};
應用程序如下：
ioctl（device，argv）；
上面這句就可以完成你的模塊中ioctl中的功能。