A. 如何學習linux設備驅動
通常，內核的升級對從事linux應用程序開發的人員來說影響較小，因為系統調用基本保持兼容，影響比較大的是驅動開發人員。每次內核的更新都可能導致許多內核函數原型上的變化，其中既有內核本身提供的函數，也有硬體平台代碼提供的函數，後者變化的更加頻繁。這一點從許多經典書籍就可驗證，當你按照手裡的經典著作，如：Alessandro的《linux設備驅動程序》，編寫驅動時，發現並不能夠成功的在你的linux平台上編譯通過、或不能正常執行，原因就在於你用的內核和書里的不一致。
本文從兩個方面去解釋這個問題，一方面是如何寫好linux設備驅動，另一方面是如何應對不斷升級的內核。
如何寫好Linux設備驅動
Linux設備驅動是linux內核的一部分，是用來屏蔽硬體細節，為上層提供標准介面的一種技術手段。為了能夠編寫出質量比較高的驅動程序，要求工程師必須具備以下幾個方面的知識：
● 熟悉處理器的性能
如：處理器的體系結構、匯編語言、工作模式、異常處理等。對於初學者來說，在還不熟悉驅動編寫方法的情況下，可以先不把重心放在這一項上，因為可能因為它的枯燥、抽象而影響到你對設備驅動的興趣。隨著你不斷地熟悉驅動的編寫，你會很自然的意識到此項的重要性。
● 掌握驅動目標的硬體工作原理及通訊協議
如：串口控制器、顯卡控制器、硬體編解碼、存儲卡控制器、I2C通訊、SPI通訊、USB通訊、SDIO通訊、I2S通訊、PCI通訊等。編寫設備驅動的前提就是需要了解設備的操作方法，所以這些內容的重要程度不言而喻。但不是說要把所有設備的操作方法都熟悉了以後才可以寫驅動，你只需要了解你要驅動的硬體就可以了。
● 掌握硬體的控制方法
如：中斷、輪詢、DMA 等，通常一個硬體控制器會有多種控制方法，你需要根據系統性能的需要合理的選擇操作方法。初學階段以實現功能為目的，掌握的順序應該是，輪詢->中斷->DMA。隨著學習的深入，需要綜合考慮系統的性能需求，採取合適的方法。
● 良好的GNU C語言編程基礎
如：C語言的指針、結構體、內存操作、鏈表、隊列、棧、C和匯編混合編程等。這些編程語法是編寫設備驅動的基礎，無論對於初學者還是有經驗者都非常重要。
● 良好的linux操作系統概念
如：多進程、多線程、進程調度、進程搶占、進程上下文、虛擬內存、原子操作、阻塞、睡眠、同步等概念及它們之間的關系。這些概念及方法在設備驅動里的使用是linux設備驅動區別單片機編程的最大特點，只有理解了它們才會編寫出高質量的驅動。
● 掌握linux內核中設備驅動的編寫介面
如：字元設備的cdev、塊設備的gendisk、網路設備的net_device，以及基於這些基本介面的framebuffer設備的fb_info、mtd設備的mtd_info、tty設備的tty_driver、usb設備的usb_driver、mmc設備的mmc_host等。
Linux內核為設備驅動編寫者提供了標準的介面，驅動編寫者無需精通內核的各個部分，只需要明確內核提供給我們的介面，並實現此介面就可以了。內核提供的介面採用的是面向對象的思路，即把目標設備抽象成一個對象，通常利用一個結構體來描述這個對象。驅動工程師的任務就是實現這個對象。這個結構體中會包含設備的屬性（用變數表示）和操作方法（用函數指針表示）。如：字元設備的cdev
struct cdev {
struct kobject kobj;
struct mole *owner;
const struct file_operations *ops; // 操作方法結合，其它項都是屬性
struct list_head list;
dev_t dev;
unsigned int count;
};
開始階段可以以模仿為主，即套用一些固定的模板、參考常式。
如何應對不斷升級的內核
內核升級對驅動的影響主要體現在，（1）驅動介面定義的變化；（2）內核的一些功能函數的名稱、參數、頭文件、宏定義的變化；（3）平台代碼關於硬體操作方面封裝的一些函數的變化；（4）設備模型的影響。
● 驅動介面定義的變化
如：2.4內核中字元設備驅動的注冊介面是：
int register_chrdev(unsigned int major, const char * name, struct file_operations *fops)
而2.6內核中已經不建議使用這種方法了，改為：
int cdev_add(struct cdev *p, dev_t dev, unsigned count)
這種介面定義及注冊方法帶來的變化，發生的並不頻繁。解決方案是：參考內核中的代碼。這種介面定義及注冊方法在內核中非常容易找到，如：字元設備驅動的注冊方法及介面定義可以參照內核driver/char/目錄下的很多實例。
● 內核的一些功能函數的名稱、參數、頭文件、宏定義的變化
如：中斷注冊函數的格式及參數在2.4內核、2.6內核低版本和高版本之間都存在差別，在2.6.8中，中斷注冊函數的定義為：
int request_irq(unsigned int irq, irqreturn_t (*handler)(int, void *, struct pt_regs *),unsigned long irq_flags, const char * devname, void *dev_id)
irq_flags的取值主要為下面的某一種或組合： SA_INTERRUPT、SA_SAMPLE_RANDOM、SA_SHIRQ
在2.6.26中，中斷注冊函數的定義為：
int request_irq(unsigned int irq, irq_handler_t handler,unsigned long irqflags, const char *devname, void *dev_id)
typedef irqreturn_t (*irq_handler_t)(int, void *); irq_flags的取值主要為下面的某一種或組合：（功能和2.6.8的對應）IRQF_DISABLED、IRQF_SAMPLE_RANDOM、IRQF_SHARED
當出現這些問題時，編譯過程中，編譯器會給我們比較明確的錯誤提示，根據這些提示你可以判斷出是否是缺少頭文件問題、是否是函數參數定義有誤等。解決問題的最好辦法還是到你的目標內核中找信息。此時找問題的方法可以藉助於搜索，如：你可以在新的內核中搜索request_irq，看新內核中的驅動是如何使用它的，這種方法非常有效。
● 平台代碼關於硬體操作方面封裝的一些函數的變化
內核中，硬體平台相關的代碼在內核更新過程中變化比較頻繁，和我們的設備驅動也是息息相關，所以在針對一個新內核編寫設備驅動前，一定要熟悉你的平台代碼的結構。有時平台雖然提供了內核要求的介面函數，但使用起來功能卻並不完善。下面還是先舉個例子說明平台代碼更新對設備驅動的影響。
如：在linux-2.6.8內核中，調用set_irq_type(IRQ_EINT0,IRQT_FALLING);去設置S3C2410的IRQ_EINT0的中斷觸發信號類型，你會發現不會有什麼效果。跟蹤代碼發現內核的set_irq_type函數需要平台提供一個針對硬體平台的實現函數
static struct irqchip s3c_irqext_chip = {
.mask = s3c_irqext_mask,
.unmask = s3c_irqext_unmask,
.ack = s3c_irqext_ack,
.type = s3c_irqext_type
};
s3c_irqext_type就是linux內核需要的實現函數，而s3c_irqext_type在2.6.8中的實現為： static int s3c_irqext_type(unsigned int irq, unsigned int type)
{
irqdbf("s3c_irqext_type: called for irq %d, type %d\n", irq, type);
return 0;
}
原來並沒有實現。而在較高版本的內核，如2.6.26內核中，這個函數是實現了的。所以你一定要小心。當平台函數不好用時，一定要查查原因，或者直接操作硬體寄存器來達到目的。
● 2.6內核設備模型對驅動的影響
在2.6內核中寫設備驅動和在2.4內核中有著很大的不同，主要就是在設備驅動中融入了比設備驅動本身結構還復雜、還難以理解的設備模型。初學驅動時你可以不理會設備模型，但你會發現內核里的驅動代碼基本上都是融入了設備模型的了。所以很多時候你不得不面對現實，還是要弄懂它，並且它也的注冊方法也會隨著內核的升級而發生變化。解決此類問題的最好方法還是參考目標內核驅動代碼。
B. Linux驅動IO篇——ioctl設備操作
在Linux驅動編程中， ioctl介面是驅動層與應用層之間的重要橋梁，用於設置或獲取驅動層的數據。學習如何在驅動中實現ioctl介面是關鍵技能。一個ioctl命令由32位編碼，遵循特定規則，參考內核文檔定義，如「Documentation/ioctl/ioctl-deconding.txt」。內核頭文件`include/uapi/asm-generic/ioctl.h`提供宏幫助定義和解析命令。
為了定義自定義ioctl命令，應遵照編碼規則，構造命令，並使用`IOW`或`IOR`宏來區分讀取和寫入操作。在實際應用中，需要確保定義的幻數在不同體系結構下具有全局唯一性，盡管實現這一目標可能具有挑戰性。
ioctl通過系統調用實現，應用層調用`ioctl`函數時，從用戶態過渡到內核態，調用`sys_ioctl`函數。`sys_ioctl`函數首先調用`security_file_ioctl`，再調用`do_vfs_ioctl`，處理特定命令，避免與現有命令沖突。
驅動層實現主要涉及`struct file_operations`結構體中的`unlocked_ioctl`函數，該函數處理用戶傳入的ioctl命令，並根據命令類型執行相應的操作。傳入的數據可通過強制類型轉換進行訪問。
示例代碼展示了如何在驅動中實現和應用ioctl介面，包括命令的定義、函數的調用以及數據的處理。通過運行示常式序，可驗證驅動層實現的正確性。
C. 解釋一下linux驅動程序結構框架及工作原理
一、Linux device driver 的概念
系統調用是操作系統內核和應用程序之間的介面，設備驅動程序是操作系統內核和機器硬體之間的介面。設備驅動程序為應用程序屏蔽了硬體的細節，這樣在應用程序看來，硬體設備只是一個設備文件，應用程序可以象操作普通文件一樣對硬體設備進行操作。設備驅動程序是內核的一部分，它完成以下的功能:
1、對設備初始化和釋放；
2、把數據從內核傳送到硬體和從硬體讀取數據；
3、讀取應用程序傳送給設備文件的數據和回送應用程序請求的數據；
4、檢測和處理設備出現的錯誤。
在Linux操作系統下有三類主要的設備文件類型，一是字元設備，二是塊設備，三是網路設備。字元設備和塊設備的主要區別是:在對字元設備發出讀/寫請求時，實際的硬體I/O一般就緊接著發生了，塊設備則不然，它利用一塊系統內存作緩沖區，當用戶進程對設備請求能滿足用戶的要求，就返回請求的數據，如果不能，就調用請求函數來進行實際的I/O操作。塊設備是主要針對磁碟等慢速設備設計的，以免耗費過多的CPU時間來等待。
已經提到，用戶進程是通過設備文件來與實際的硬體打交道。每個設備文件都都有其文件屬性(c/b)，表示是字元設備還是塊設備?另外每個文件都有兩個設備號，第一個是主設備號，標識驅動程序，第二個是從設備號，標識使用同一個設備驅動程序的不同的硬體設備，比如有兩個軟盤，就可以用從設備號來區分他們。設備文件的的主設備號必須與設備驅動程序在登記時申請的主設備號一致，否則用戶進程將無法訪問到驅動程序。
最後必須提到的是，在用戶進程調用驅動程序時，系統進入核心態，這時不再是搶先式調度。也就是說，系統必須在你的驅動程序的子函數返回後才能進行其他的工作。如果你的驅動程序陷入死循環，不幸的是你只有重新啟動機器了，然後就是漫長的fsck。
二、實例剖析
我們來寫一個最簡單的字元設備驅動程序。雖然它什麼也不做，但是通過它可以了解Linux的設備驅動程序的工作原理。把下面的C代碼輸入機器，你就會獲得一個真正的設備驅動程序。
由於用戶進程是通過設備文件同硬體打交道，對設備文件的操作方式不外乎就是一些系統調用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系統調用和驅動程序關聯起來呢?這需要了解一個非常關鍵的數據結構：
STruct file_operatiONs {
int (*seek) (struct inode * ，struct file *， off_t ，int);
int (*read) (struct inode * ，struct file *， char ，int);
int (*write) (struct inode * ，struct file *， off_t ，int);
int (*readdir) (struct inode * ，struct file *， struct dirent * ，int);
int (*select) (struct inode * ，struct file *， int ，select_table *);
int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long);
int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *);
int (*open) (struct inode * ，struct file *);
int (*release) (struct inode * ，struct file *);
int (*fsync) (struct inode * ，struct file *);
int (*fasync) (struct inode * ，struct file *，int);
int (*check_media_change) (struct inode * ，struct file *);
int (*revalidate) (dev_t dev);
}
這個結構的每一個成員的名字都對應著一個系統調用。用戶進程利用系統調用在對設備文件進行諸如read/write操作時，系統調用通過設備文件的主設備號找到相應的設備驅動程序，然後讀取這個數據結構相應的函數指針，接著把控制權交給該函數。這是linux的設備驅動程序工作的基本原理。既然是這樣，則編寫設備驅動程序的主要工作就是編寫子函數，並填充file_operations的各個域。
下面就開始寫子程序。
#include <linux/types.h> 基本的類型定義
#include <linux/fs.h> 文件系統使用相關的頭文件
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/segment.h>
unsigned int test_major = 0;
static int read_test(struct inode *inode，struct file *file，char *buf，int count)
{
int left; 用戶空間和內核空間
if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )
return -EFAULT;
for(left = count ; left > 0 ; left--)
{
__put_user(1，buf，1);
buf++;
}
return count;
}
這個函數是為read調用准備的。當調用read時，read_test()被調用，它把用戶的緩沖區全部寫1。buf 是read調用的一個參數。它是用戶進程空間的一個地址。但是在read_test被調用時，系統進入核心態。所以不能使用buf這個地址，必須用__put_user()，這是kernel提供的一個函數，用於向用戶傳送數據。另外還有很多類似功能的函數。請參考，在向用戶空間拷貝數據之前，必須驗證buf是否可用。這就用到函數verify_area。為了驗證BUF是否可以用。
static int write_test(struct inode *inode，struct file *file，const char *buf，int count)
{
return count;
}
static int open_test(struct inode *inode，struct file *file )
{
MOD_INC_USE_COUNT; 模塊計數加以，表示當前內核有個設備載入內核當中去
return 0;
}
static void release_test(struct inode *inode，struct file *file )
{
MOD_DEC_USE_COUNT;
}
這幾個函數都是空操作。實際調用發生時什麼也不做，他們僅僅為下面的結構提供函數指針。
struct file_operations test_fops = {?
read_test，
write_test，
open_test，
release_test，
};
設備驅動程序的主體可以說是寫好了。現在要把驅動程序嵌入內核。驅動程序可以按照兩種方式編譯。一種是編譯進kernel，另一種是編譯成模塊(moles)，如果編譯進內核的話，會增加內核的大小，還要改動內核的源文件，而且不能動態的卸載，不利於調試，所以推薦使用模塊方式。
int init_mole(void)
{
int result;
result = register_chrdev(0， "test"， &test_fops); 對設備操作的整個介面
if (result < 0) {
printk(KERN_INFO "test: can't get major number\n");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}
在用insmod命令將編譯好的模塊調入內存時，init_mole 函數被調用。在這里，init_mole只做了一件事，就是向系統的字元設備表登記了一個字元設備。register_chrdev需要三個參數，參數一是希望獲得的設備號，如果是零的話，系統將選擇一個沒有被佔用的設備號返回。參數二是設備文件名，參數三用來登記驅動程序實際執行操作的函數的指針。
如果登記成功，返回設備的主設備號，不成功，返回一個負值。
void cleanup_mole(void)
{
unregister_chrdev(test_major，"test");
}
在用rmmod卸載模塊時，cleanup_mole函數被調用，它釋放字元設備test在系統字元設備表中佔有的表項。
一個極其簡單的字元設備可以說寫好了，文件名就叫test.c吧。
下面編譯 :
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c –c表示輸出制定名，自動生成.o文件
得到文件test.o就是一個設備驅動程序。
如果設備驅動程序有多個文件，把每個文件按上面的命令行編譯，然後
ld ?-r ?file1.o ?file2.o ?-o ?molename。
驅動程序已經編譯好了，現在把它安裝到系統中去。
$ insmod ?–f ?test.o
如果安裝成功，在/proc/devices文件中就可以看到設備test，並可以看到它的主設備號。要卸載的話，運行 :
$ rmmod test
下一步要創建設備文件。
mknod /dev/test c major minor
c 是指字元設備，major是主設備號，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices
就可以獲得主設備號，可以把上面的命令行加入你的shell script中去。
minor是從設備號，設置成0就可以了。
我們現在可以通過設備文件來訪問我們的驅動程序。寫一個小小的測試程序。
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test"，O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file \n");
exit(0);
}
read(testdev，buf，10);
for (i = 0; i < 10;i++)
printf("%d\n"，buf[i]);
close(testdev);
}
編譯運行，看看是不是列印出全1
以上只是一個簡單的演示。真正實用的驅動程序要復雜的多，要處理如中斷，DMA，I/O port等問題。這些才是真正的難點。上述給出了一個簡單的字元設備驅動編寫的框架和原理，更為復雜的編寫需要去認真研究LINUX內核的運行機制和具體的設備運行的機制等等。希望大家好好掌握LINUX設備驅動程序編寫的方法。
D. vc++如何給窗體添加背景圖片
VC是一個功能強大的可視化的開發工具，但是用VC做的標准界面與Windows一樣色彩灰暗單調，例如多文檔窗口應用程序中的主框架窗口的背景便是如此。那麼能否給主框架窗口的背景改變一下色彩或是給主框架窗口加上一幅漂亮的圖片做背景？其實也不難。但與單文檔窗口應用程序中改變框架窗口的背景方法不同，對多文檔窗口應用程序中的主框架窗口改變背景不能簡單地用ClassWizard重載OnEraseBkgnd(CDC＊ pDC)函數的方法實現。因為多文檔窗口應用程序中的主框架窗口的背景區是一個MDIClient類的窗口，因此改變背景與這個MDIClient類的窗口有關。MDIClient類的窗口的句柄是m_hWndMDIClient(在CMDIFrameWnd中)。以下是其實現的步驟：
一、 使用MFC AppWizard向導創建一個多文檔窗口應用程序
1、在VC的「File」菜單中單擊[New]，彈出一「New」對話框。在「Projects」頁中選擇「MFC AppWizard [exe]」，在「Project name」編輯框中輸入「DrawBackground」，按[OK]按鈕，退出「New」對話框。
2、在「MFC AppWizard step 1」對話框到「MFC AppWizard step 6」對話框中選擇默認選項，按[Finish]按鈕即完成多文檔窗口應用程序的定製。
註：MFC(Microsoft Foundation Class)是MS－Visual C＋＋的類庫。
二、向應用程序添加點陣圖
在VC的「View」菜單中單擊「Resource Includes...」, 在彈出對話框中選擇「Bitmap」， 按[Import]按鈕從文件中載入點陣圖文件，單擊「Workspace」的「Resource」便可見到剛才載入的點陣圖文件，默認的資源標識符為IDB_BITMAP1。
三、用ClassWiard生成一個 CWnd 類的派生類CclientWnd
在CclientWnd類中重載OnEraseBkgnd(CDC＊ pDC)，OnSize(UINT nType, int cx, int cy)函數，並用手工加入重載的虛函數WNDPROC＊ CClientWnd::GetSuperWndProcAddr()用來返回函數指針。
類CclientWnd的頭文件代碼如下：
class CClientWnd : public CWnd
{
// Construction
public:
CClient();
// Attributes
public:
// Operations
public:
// Overrides
// ClassWizard generated virtual function overrides
file://{{AFX_VIRTUAL(CClientWnd)
public:
virtual WNDPROC＊ GetSuperWndProcAddr();
file://}}AFX_VIRTUAL
// Implementation
public:
virtual ～CClientWnd();
// Generated message map functions
protected:
file://{{AFX_MSG(CClientWnd)
afx_msg BOOL OnEraseBkgnd(CDC＊ pDC);
afx_msg void OnSize(UINT nType, int cx, int cy);
file://}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
類CclientWnd的實現文件代碼如下：
// CClientWnd message handlers
BOOL CClientWnd::OnEraseBkgnd(CDC＊ pDC)
{
// TODO: Add your message handler code here and/or call default
CRect rectbk; // 客戶區的大小
CDC dcMen; // 內存設備描述表
CBitmap bmbk; // 點陣圖對象
bmbk.LoadBitmap(IDB_BITMAP1); // 從資源載入點陣圖 bitmap
// 得到點陣圖bitmap的大小
BITMAP stBitmap;
bmbk.GetObject(sizeof(BITMAP),＆stBitmap);
CSize bmsize(stBitmap.bmWidth,stBitmap.bmHeight);
////////
dcMen.CreateCompatibleDC(pDC); // 創建兼容的設備描述表
// 選入新的點陣圖對象並保存舊的點陣圖對象
CBitmap ＊pold=dcMen.SelectObject(＆bmbk);
GetClientRect(＆rectbk);
// 取得客戶區的大小
// 從內存向屏幕復制點陣圖對象
pDC－>StretchBlt(rectbk.left,rectbk.top,rectbk.Width(),
rectbk.Height(),＆dcMen,0,0,bmsize.cx,bmsize.cy,SRCCOPY);
dcMen.SelectObject(pold);
// 恢復舊的點陣圖對象 dcMen.DeleteDC();// 釋放內存設備描述表 return true; }
WNDPROC＊ CClientWnd::GetSuperWndProcAddr()
{static WNDPROC NEAR pfnSuper = NULL; return ＆pfnSuper; // 返回函數指針 }
void CClientWnd::OnSize(UINT nType, int cx, int cy)
{CWnd::OnSize(nType, cx, cy);// TODO: Add your message handler code here file://重畫窗口Invalidate(); }
四、修改CMainFrame類
在CMainFrame類中定義一個CClientWnd 類的成員變數m_wndClient，並在CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)函數中把m_wndClient子類化為主框架窗口的客戶窗口。代碼如下：
在MainFrm.h 中加入：
＃include "ClientWnd1.h"
class CMainFrame : public CMDIFrameWnd
{private: CClientWnd m_wndClient;};
MainFrm.cpp 中加入代碼如下：
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{if (CMDIFrameWnd::OnCreate(lpCreateStruct) == －1)
return －1;
file://把m_wndClient子類化為主框架窗口的客戶窗口
if(!m_wndClient.SubclassWindow(m_hWndMDIClient))
{TRACE("Fail to subclass MDI client window\n");
return －1;}}
五、關鍵技術
1、本程序並不復雜，關鍵是要知道多文檔窗口應用程序中的主框架窗口的背景區是一個MDIClient類的窗口。
2、選用函數要正確，如CClientWnd::OnEraseBkgnd(CDC＊ pDC)函數中選用GetClientRect(＆rectbk) 函數來取得客戶區的大小要比選用GetClipBox(＆rectbk) 函數來得好。
3、要在CclientWnd類中重載OnSize(UINT nType, int cx, int cy) 函數，並加入Invalidate() 函數重畫窗口。