2011年4月22日 星期五

中斷 part 2

1.5 Interrupt Flow Handling (中斷流處理)
前面提到了 IRQ 子系統的三個 抽象層: High-level interrupt Service routine, Interrupt Flow Handling, Chip-level hardware Encapsulation. 本節描述 Interrupt Flow Handling 的過程, 即, 處理邊沿觸發、水準觸發等等的過程。
1.5.1 設置控制硬體 (Setting Controller Hardware)
內核提供了一些標準函數用於註冊 irq_chips 和設置 flow handlers ,如下:
int  set_irq_chip(unsigned int irq, struct irq_chip *chip);
int set_irq_handler(unsigned int irq, irq_flow_handler_t handle)
int  set_irq_chip_data(unsigned int irq, void *data);
void set_irq_chip_and_handler(unsigned int irq, struct irq_chip *chip,
                              irq_flow_handler_t handle);
void set_irq_chip_and_handler_name(unsigned int irq, struct irq_chip *chip,
                                   irq_flow_handler_t handle, const char *name);
  • set_irq_chip: 該函數用於將一個 IRQ Chip (irq_chip 的實例) 與一個特定的中斷相關聯。 除了從 irq_desc 中選擇合適的元素外,該函數還負責設置 chip 中的指標, 並且設置預設的中斷處理函數。
  • set_irq_handler set_irq_chained_handler: 為指定的 IRQ 設置 flow handler function, 兩者在內部均使用 __set_irq_handler __set_irq_handler 進行一些檢查,並設置 irq_desc[irq]->handle_irq.
  • set_chip_and_handler: 一個輔助函數,使用它可以避免逐個的使用前面提到的三個函數。
1.5.2 Flow Handling
前面提到,中斷有不同的觸發方式: edge-trggering 或者 level-triggering, 內核對他們的處理方式有所不同。但相同的是,這兩個處理中,都需要在 flow-handling 完成後負責調用 high-level 的中斷處理函數。
  • 邊沿觸發中斷 (Edge-Triggered Interrupts)
邊沿觸發方式在現代的硬體中是最常見的一種方式,該方式的預設處理函數為 handle_edge_irq .
邊沿觸發中斷,在處理時候一般無需禁用該中斷源。這樣,在多處理器系統上,可能會出現這種情況: 一個處理器上正在處理這個Flow-Handnle,此時在這個處理過程尚未完成的時候,又產生了另外一個邊沿觸發的中斷。 對於這種情況, handler_edge_irq 的處理方法是:先更新這個 irq irq_desc 上的狀態為 PENDING, 然後暫時將這個中斷 mask 掉(這裡的 mask 是通過 irq_chip 結構提供的函數在硬體上操作,而不是內核中軟體意義上的 mask); 而前面負責處理這個 irq CPU , 在處理完了一個 IRQ 後,檢查這個 irq_desc 的狀態,如果為 PENDING, 則表示在前面的處理過程中又有新的中斷信號產生了,需要繼續處理,直到這個 irq_desc 的狀態不是 PENDING 為止。
Flow-Handle 的每個迴圈的結尾, hander_edge_irq 都會以 iqd_desc->action 為參數來通過 handleIRQevent 調用 High-level 處理函數。
整體流程如下圖所示:


                  handle_edge_irq 流程
  • 水準觸發中斷 (Level-Triggered Interrupts)
Level-Triggered Interrups 由函數 handle_level_irq 負責處理,他的流程比 handle_edge_irq 要簡單一些, 如下圖所示:


handle_level_irq 流程
需要注意的是, Level-Triggered Interrups 在處理的時候必須要將其 Mask 掉,這個 Mask 的過程通過函數 mask_ack_irq 來完成。 maks_ack_irq 不但將 irq_desc 的狀態設置為 mask ,同時還調用了 chip->mask_ack 來設置硬體的 mask , 並向硬體發送 ACK 對於多核 CPU 所潛在的競爭冒險1,可以通過檢測 irq_desc 的狀態來避免 —— 一旦檢測到 irq_desc->status 中包含了 IRQ_INPROGRESS ,則表明該 irq 正在被處理,直接退出即可。
同邊沿觸發的處理一樣,這裡也通過 handle_IRQ_event 來調用了 High-level 的處理函數。
  • 其他類型的中斷
除了上述兩種類型的的中斷之外,還有一些其他不常用的中斷,內核為他們提供了默認的 handler
    • handle_fasteoi_irq
很多現代的 IRQ 硬體僅需要做一點點流處理工作 (Flow-Handle),對他們來講,在 IRQ 處理完畢之後, 只需要調用一個 Chip-specific 的函數: chip->eoi 就可以了, 函數 handle_fasteoi_irq 負責這個工作。
    • handle_simple_irq
一些實在是很簡單的中斷根本就不需要流控制,內核為他們提供了 handle_simple_irq
    • handle_percpu_irq
有些 IRQ 只能發上在 SMP 上的某個指定的 CPU 上,這種 IRQ 被成為 Per-CPU IRQ , 內核提供了 handle_percpu_irq 來處理他們。該函數負責在中斷處理完成之後向硬體彙報中斷的接收,並調用 EOI
1.6 IRQ 的初始化及預留
1.6.1 IRQ 的註冊
函數 request_irq 用於註冊 IRQ , 其定義為:
static inline int __must_check
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
        const char *name, void *dev)
{
    return request_threaded_irq(irq, handler, NULL, flags, name, dev);
}
可見,該函數是 request_threaded_irq 的一個 wrapper ,並將 request_threaded_irq 的參數 thread_fn 設置為空。 request_threaded_irq 的流程圖如下圖所示:


request_threaded_irq
該函數首先從內核中獲取了這個 irq 對應的 irq_desc, 然後創建 irqaction, 設置這個 action handler, flags, name, dev_id 。 隨後,將其餘的工作交給了函數 __setup_irq, 由 __setup_irq 完後後續的工作。
__setup_irq 的主要作用如下:
  • 設置內核熵池
前面提到過,內核通過一系列的事件的相關資訊來生成亂數 (/dev/random),這裡,如果傳入的 flags 中聲明了 IRQF_SAMPLE_RANDOM ,則調用 rand_initialize_irq IRQ 添加到熵池所需的相關資料結構中。
  • 添加 irqaction
前面提到,內核有一個全域的 irq_desc Array, 從這個 Array 中可以根據 IRQ Number 來找到相應的 irq_desc ; 此外,每個 irq_desc 中有一個 irqaction list ,這個 list 中記錄了該 irq 中斷發生時候需要調用的每一個 irqaction __setup_irq 需要將傳入的 irqaction 添加到這個 list 的隊尾。
  • 其他的 irq flags 檢查
根據傳入參數的flags, 做一些別的檢查和設置,沒具體細看。
  • 註冊 proc 檔案系統
__setup_irq 的最後,調用 register_irq_proc ,在 proc/irq 中為相應的 IRQ 創建了節點。 然後又調用 register_handler_proc , 生成/proc/irq/NUM/NAME 。從而使用戶可以從 procfs 中得到該 IRQ 的信息。
1.6.2 釋放 IRQ
在釋放 IRQ 的時候,僅提供一個 IRQ Number 不行的,還必須提供這個 IRQ 對應的 dev_id. 該過程由函數 free_irq 來完成, free_irq __free_irq 的一個包裝,調 用 __free_irq 來完成 irqaction 的註銷。
__free_irq 根據傳入的 dev_id 從這個 IRQ 的所有 irqaction 上找到設備對應的那個 irqaction , 並將其從 IRQ irqaction List 中移走; 如果移走的這個 handler 是這個 IRQ Line 上唯一的一個, 那麼還需要將這個 IRQ Line Diable。隨後,清理 proc 檔案系統中的結點, 並將 action 這個結構返回給 free_irq, free_irq 負責將資料結構 free
1.6.3 中斷的註冊 (Registering Interrupts, 指系統中斷)
前面提到的 irq_request 僅用於外設的 IRQ 申請, 而對於 CPU 本身已經軟體上的中斷,處理的流程與此不同。 諸如軟體發出的中斷、異常以及陷阱,這些東西的註冊是在系統初始化的時候執行的,並且初始化完成之後,在整個系統的活動週期內不會發生改變。由於系統的中斷是不能共用的(也沒有必要共用,資源多得很),內核所需要做的,僅僅是將中斷號和處理函數相關聯。
一般來講,內核對於這種系統中斷的回應有如下兩種:
  • 當錯誤發生的時候,向當前使用者進程發送信號:
例如,在 IA-32 AMD64 系統,當一個數位被0除的時候,會產生中斷 0 , 這個中斷會調用處理函數 divide_error ,並向使用者進程發送信號 —— SIGPFE
  • 錯誤發生後, 內核自動校正錯誤:
例如 IA-32 系統下, 中斷 14 被用來作為 page fault (記憶體卻頁或者分頁錯誤)的信號,當這個錯誤發生的時候,內核可以自動對該錯誤進行糾正。
Footnotes:
1 競爭冒險和前面提到的邊沿觸發中斷的嵌套不同,由於處理 Level-Triggered Interrups 時候, 中斷源那個硬體已經被暫時 Mask 掉,因此在一個水準觸發中斷的處理期間,同一個設備不會產生另外一個水準觸發中斷。 因此,競爭冒險指的是多個 CPU 同時選定要處理同一個 irq

2011年4月21日 星期四

Sparse工具檢測使用的屬性定義

 下面分析一下sparse所能檢查的相關屬性。

# define __user                __attribute__((noderef, address_space(1)))
# define __kernel        /* default address space */
# define __safe                __attribute__((safe))
# define __force        __attribute__((force))
# define __nocast        __attribute__((nocast))
# define __iomem        __attribute__((noderef, address_space(2)))
# define __acquires(x)        __attribute__((context(x,0,1)))
# define __releases(x)        __attribute__((context(x,1,0)))
# define __acquire(x)        __context__(x,1)
# define __release(x)        __context__(x,-1)
# define __cond_lock(x,c)        ((c) ? ({ __acquire(x); 1; }) : 0)
extern void __chk_user_ptr(const volatile void __user *);
extern void __chk_io_ptr(const volatile void __iomem *);


__user特性用來修飾一個變數的位址,該變數必須是非解除參考(no dereference)即地址是有效的,並且變數所在的位址空間必須為1,這裡為(address_space(1)),用戶位址空間。sparse把位址空間分為3部分,0表示普通位址空間,對內核來說就是位址空間。1表示用戶位址空間。2表示設備位址映射空間,即設備寄存器的位址空間。

__kernel特性修飾變數為內核位址,為內核代碼裡面默認的位址空間。

__safe特性聲明該變數為安全變數,這是為了避免在內核函數未對傳入的參數進行校驗就使用的情況下,會導致編譯器對其報錯或輸出告警資訊。通過該特性說明該變數不可能為空。

__force特性聲明該變數是可以強制類型轉換的。

__nocast聲明該變數參數類型與實際參數類型要一致才可以。

__iomem聲明位址空間是設備位址映射空間,其他的與__user一樣。

__acquires為函數屬性定義的修飾,表示函數內,該參數的引用計數值從1變為0

__releases__acquires相反,這一對修飾符用於Sparse在靜態代碼檢測時,檢查調用的次數和匹配請求,經常用於檢測lock的獲取和釋放。

__acquire表示增加變數x的計數,增加量為1

__release表示減少變數x的計數,減少量為1。這一對與上面的那一對是一樣,只是這一對用在函數的執行過程中,都用於檢查代碼中出現不平衡的狀況。

 __cond_lock用於表示條件鎖,當c這個值不為0時,計數值加1,並返回1

__chk_user_ptr__chk_io_ptr在這裡只聲明函數,沒有函數體,目的就是在編譯過程中Sparse能夠捕捉到編譯錯誤,檢查參數的類型。

2011年4月10日 星期日

[轉]Resouce, platform_device 和 platform_driver 的關係

從2.6版本開始引入了platform這個概念,在開發底層驅動程序時,首先要確認的就是設備的資源信息,例如設備的地址,
在2.6內核中將每個設備的資源用結構platform_device來描述,該結構體定義在kernel\include\linux\platform_device.h中,
struct platform_device {
 const char * name;
 u32  id;
 struct device dev;
 u32  num_resources;
 struct resource * resource;
};
該結構一個重要的元素是resource,該元素存入了最為重要的設備資源信息,定義在kernel\include\linux\ioport.h中,
struct resource {
 const char *name;
 unsigned long start, end;
 unsigned long flags;
 struct resource *parent, *sibling, *child;
};
下面舉個例子來說明一下:
在kernel\arch\arm\mach-pxa\pxa27x.c定義了
tatic struct resource pxa27x_ohci_resources[] = {
 [0] = {
  .start  = 0x4C000000,
  .end    = 0x4C00ff6f,
  .flags  = IORESOURCE_MEM,
 },
 [1] = {
  .start  = IRQ_USBH1,
  .end    = IRQ_USBH1,
  .flags  = IORESOURCE_IRQ,
 },
};
這裡定義了兩組resource,它描述了一個usb host設備的資源,第1組描述了這個usb host設備所佔用的總線地址範圍,IORESOURCE_MEM表示第1組描述的是內存類型的資源信息,第2組描述了這個usb host設備的中斷號,IORESOURCE_IRQ表示第2組描述的是中斷資源信息。設備驅動會根據flags來獲取相應的資源信息。

有了resource信息,就可以定義platform_device了:
static struct platform_device ohci_device = {
 .name  = "pxa27x-ohci",
 .id  = -1,
 .dev  = {
  .dma_mask = &pxa27x_dmamask,
  .coherent_dma_mask = 0xffffffff,
 },
 .num_resources  = ARRAY_SIZE(pxa27x_ohci_resources),
 .resource       = pxa27x_ohci_resources,
};
有了platform_device就可以呼叫函數platform_add_devices向系統中添加該設備了,這裡的實現是
static int __init pxa27x_init(void)
{
 return platform_add_devices(devices, ARRAY_SIZE(devices));
}
這裡的pxa27x_init必須在設備驅動加載之前被呼叫,可以把它放到
subsys_initcall(pxa27x_init);
驅動程序需要實現結構體struct platform_driver,參考kernel\driver\usb\host\ohci-pxa27.c,
static struct platform_driver ohci_hcd_pxa27x_driver = {
 .probe  = ohci_hcd_pxa27x_drv_probe,
 .remove  = ohci_hcd_pxa27x_drv_remove,
#ifdef CONFIG_PM
 .suspend = ohci_hcd_pxa27x_drv_suspend,
 .resume  = ohci_hcd_pxa27x_drv_resume,
#endif
 .driver  = {
  .name = "pxa27x-ohci",
 },
};
在驅動初始化函數中呼叫函數platform_driver_register()註冊platform_driver,需要注意的是 ohci_device結構中name元素和ohci_hcd_pxa27x_driver結構中driver.name必須是相同的,這樣在 platform_driver_register()註冊時會對所有已註冊的所platform_device中的name和當前註冊的 platform_driver的driver.name進行比較,只有找到相同的名稱的platfomr_device才能註冊成功,當註冊成功時會呼叫platform_driver結構元素probe函數指針,這裡就是ohci_hcd_pxa27x_drv_probe。

當進入probe函數後,需要獲取設備的資源信息,獲取資源的函數有:
struct resource * platform_get_resource(struct platform_device *dev, unsigned int type, unsigned int num);

根據參數type所指定類型,例如IORESOURCE_MEM,來獲取指定的資源。
struct int platform_get_irq(struct platform_device *dev, unsigned int num);
獲取資源中的中斷號。

struct resource * platform_get_resource_byname(struct platform_device *dev, unsigned int type, char *name);
根據參數name所指定的名稱,來獲取指定的資源。

int platform_get_irq_byname(struct platform_device *dev, char *name);
根據參數name所指定的名稱,來獲取資源中的中斷號。

platform_driver架構

platform_driver架構

分類:LINUX
2010/07/16 18:40
 
首先介紹一下註冊一個驅動的步驟:
1、定義一個platform_driver架構
2、起始化這個架構,指定其proberemove等函數,并起始化其中的driver變數
3、實現其proberemove等函數

platform_driver架構,定義于include/linux/platform_device.h檔案中:
struct platform_driver {
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*suspend_late)(struct platform_device *, pm_message_t state);
int (*resume_early)(struct platform_device *);
int (*resume)(struct platform_device *);
struct device_driver driver;
};

可見,它包含了裝置作業的几個功能函數,同樣重要的是,它還包含了一個device_driver架構。剛才提到了驅動程式中需要起始化這個變數。下面看一下這個變數的定義,位于include/linux/device.h中:
struct device_driver {
const char * name;
struct bus_type * bus;
struct kobject kobj;
struct klist klist_devices;
struct klist_node knode_bus;
struct module * owner;
const char * mod_name; /* used for built-in modules */
struct module_kobject * mkobj;
int (*probe) (struct device * dev);
int (*remove) (struct device * dev);
void (*shutdown) (struct device * dev);
int (*suspend) (struct device * dev, pm_message_t state);
int (*resume) (struct device * dev);
};

需要注意這兩個變數:nameowner。那么的作用主要是為了和相關的platform_device關聯起來,owner的作用是說明模組的所有者,驅動程式中一般起始化為THIS_MODULE
下面是一個platform_driver的起始化實例:
static struct platform_driver s3c2410iis_driver = {
.probe = s3c2410iis_probe,
.remove = s3c2410iis_remove,
.driver = {
.name = "s3c2410-iis",
.owner = THIS_MODULE,
},
};
上面的起始化是一個聲訊驅動的實例。注意其中的driver這個架構體,只起始化了其nameowner兩個量。接着看一下和driver相關的另一個架構,定義如下:
struct platform_device {
const char * name;
int id;
struct device dev;
u32 num_resources;
struct resource * resource;
};

該架構中也有一個name變數。platform_driver從字面上來看就知道是裝置驅動。裝置驅動是為誰服務的呢?當然是裝置了。platform_device就說明了裝置物件。下面是一個具體的實例:
struct platform_device s3c_device_iis = {
.name = "s3c2410-iis",
.id = -1,
.num_resources = ARRAY_SIZE(s3c_iis_resource),
.resource = s3c_iis_resource,
.dev = {
.dma_mask = &s3c_device_iis_dmamask,
.coherent_dma_mask = 0xffffffffUL
}
};

它的name變數和剛才上面的platform_drivername變數是一致的,核心正是通過這個一致性來為驅動程式找到資源,即platform_device中的resource。這個架構的定義如下,位于include/linux/ioport.h中:
struct resource {
resource_size_t start;
resource_size_t end;
const char *name;
unsigned long flags;
struct resource *parent, *sibling, *child;
};

下面是一個具體的實例:
static struct resource s3c_iis_resource[] = {
[0] = {
.start = S3C24XX_PA_IIS,
.end = S3C24XX_PA_IIS + S3C24XX_SZ_IIS -1,
.flags = IORESOURCE_MEM,
}
};

這個架構的作用就是告訴驅動程式裝置的起始位址和終止位址和裝置的通訊埠類別。這裡的位址指的是實體位址。
另外還需要注意platform_device中的device架構,它詳細說明了裝置的情況,定義如下:
struct device {
struct klist klist_children;
struct klist_node knode_parent; /* node in sibling list */
struct klist_node knode_driver;
struct klist_node knode_bus;
struct device *parent;
struct kobject kobj;
char bus_id[BUS_ID_SIZE]; /* position on parent bus */
struct device_type *type;
unsigned is_registered:1;
unsigned uevent_suppress:1;
struct semaphore sem; /* semaphore to synchronize calls to
* its driver.
*/
struct bus_type * bus; /* type of bus device is on */
struct device_driver *driver; /* which driver has allocated this
device */
void *driver_data; /* data private to the driver */
void *platform_data; /* Platform specific data, device
core doesn't touch it */
struct dev_pm_info power;
#ifdef CONFIG_NUMA
int numa_node; /* NUMA node this device is close to */
#endif
u64 *dma_mask; /* dma mask (if dma'able device) */
u64 coherent_dma_mask;/* Like dma_mask, but for
alloc_coherent mappings as
not all hardware supports
64 bit addresses for consistent
allocations such descriptors. */
struct list_head dma_pools; /* dma pools (if dma'ble) */
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
/* arch specific additions */
struct dev_archdata archdata;
spinlock_t devres_lock;
struct list_head devres_head;
/* class_device migration path */
struct list_head node;
struct class *class;
dev_t devt; /* dev_t, creates the sysfs "dev" */
struct attribute_group **groups; /* optional groups */
void (*release)(struct device * dev);
};

上面把驅動程式中涉及到的主要架構都介紹了,下面主要說一下驅動程式中怎樣對這個架構進行處理,以使驅動程式能執行。
相信大家都知道module_init()這個巨集。驅動模組加載的時候會呼叫這個巨集。它接收一個函數為參數,作為它的參數的函數將會對上面提到的platform_driver進行處理。看一個實例:假如這裡module_init要接收的參數為s3c2410_uda1341_init這個函數,下面是這個函數的定義:
static int __init s3c2410_uda1341_init(void) {
memzero(&input_stream, sizeof(audio_stream_t));
memzero(&output_stream, sizeof(audio_stream_t));
return platform_driver_register(&s3c2410iis_driver);
}

注意函數體的最后一行,它呼叫的是platform_driver_register這個函數。這個函數定義于driver/base/platform.c中,原型如下:
int platform_driver_register(struct platform_driver *drv)
它的功能就是為上面提到的plarform_driver中的driver這個架構中的proberemove這些變數指定功能函數。

到目前為止,核心就已經知道了有這么一個驅動模組。核心啟動的時候,就會呼叫與該驅動相關的probe函數。我們來看一下probe函數實現了什么功能。

probe函數的原型為
int xxx_probe(struct platform_device *pdev)

即它的傳回類別為int,接收一個platform_device類別的指標作為參數。傳回類別就是我們熟悉的錯誤程式碼了,而接收的這個參數呢,我們上面已經說過,驅動程式為裝置服務,就需要知道裝置的資訊。而這個參數,就包含了與裝置相關的資訊。
probe函數接收到plarform_device這個參數后,就需要從中擷取出需要的資訊。它一般會通過呼叫核心提供的platform_get_resourceplatform_get_irq等函數來獲得相關資訊。如通過platform_get_resource獲得裝置的起始位址后,可以對其進行request_mem_regionioremap等作業,以便應用程式對其進行作業。通過platform_get_irq得到裝置的中斷號以后,就可以呼叫request_irq函數來向系統申請中斷。這些作業在裝置驅動程式中一般都要完成。

在完成了上面這些工作和一些其他必須的起始化作業后,就可以向系統註冊我們在/dev目錄下能看在的裝置檔案了。舉一個例子,在聲訊晶片的驅動中,就可以呼叫register_sound_dsp來註冊一個dsp裝置檔案,lcd的驅動中就可以呼叫register_framebuffer來註冊fb裝置檔案。這個工作完成以后,系統中就有我們需要的裝置檔案了。而和裝置檔案相關的作業都是通過一個file_operations 來實現的。在呼叫register_sound_dsp等函數的時候,就需要傳遞一個file_operations 類別的指標。這個指標就提供了可以供用戶空間呼叫的writeread等函數。file_operations架構的定義位于include/linux/fs.h中,列出如下:

struct file_operations {
struct module *owner;
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
int (*readdir) (struct file *, void *, filldir_t);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
int (*mmap) (struct file *, struct vm_area_struct *);
int (*open) (struct inode *, struct file *);
int (*flush) (struct file *, fl_owner_t id);
int (*release) (struct inode *, struct file *);
int (*fsync) (struct file *, struct dentry *, int datasync);
int (*aio_fsync) (struct kiocb *, int datasync);
int (*fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
int (*check_flags)(int);
int (*dir_notify)(struct file *filp, unsigned long arg);
int (*flock) (struct file *, int, struct file_lock *);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
int (*setlease)(struct file *, long, struct file_lock **);
};
到目前為止,probe函數的功能就完成了。
當用戶開啟一個裝置,并呼叫其readwrite等函數的時候,就可以通過上面的file_operations來找到相關的函數。所以,用戶驅動程式還需要實現這些函數,具體實現和相關的裝置有密切的關係,這裡就不再介紹了。