[轉]QNX總結-QNX資源管理器

如果你認爲本系列文章對你有所幫助，請大家有錢的捧個錢場，點擊此處贊助，贊助額0.1元起步，多少隨意

聲明：本文只用於個人學習交流，若不慎造成侵權，請及時聯繫我，立即予以改正

鋒影

email:[email protected]

 

1. Introduction

QNX Neutrino允許用戶編寫進程充當資源管理器，並且可以動態的啓動和停止。這樣的好處是可以降低系統在運行時的內存需求，並且可以靈活的應對定製化嵌入式系統中的各種設備。

資源管理器通常負責向各類設備提供接口，這些設備可能涉及管理實際的硬件設備（比如串口、並口、網卡或磁盤驅動器）或虛擬設備（比如/dev/null、網絡文件系統、僞ttys等）

在其他操作系統中，這個功能通常與設備驅動程序相關聯，與設備驅動程序不同的是資源管理器不需要與內核進行耦合，看起來更像是用戶級程序。

2. What is a resource manager?

資源管理器是用戶級的服務器程序，它接收來自其他程序的請求服務，並可選的與硬件進行通信。QNX Neutrino強大和靈活的本地IPC機制，可以讓資源管理器與內核解耦合。

由於QNX Neutrino是一個分佈式微內核操作系統，幾乎所有非內核功能都由用戶可安裝的程序提供，因此客戶端程序與資源管理器之間需要一個定義清晰與良好的接口，並對資源管理器的功能進行文檔化。

在路徑名空間映射中，進程管理器會將路徑名和資源管理器進行映射綁定，比如串口可以由資源管理器devc-ser*管理，但是實際的路徑名空間中名稱爲dev/ser1，可以通過打開dev/ser1來獲取串口服務。

2.1 Why write a resource manager?

編寫一個資源管理器有以下幾個原因：

• 客戶端使用POSIX接口與資源管理器通信；
• 可以減少接口類型的數量，當有很多服務器進程時，將服務器進程都編寫成資源管理器，可以最大化減少客戶端需要使用的接口數量；
• 可以使用命令行工具與資源管理器通信，比如cat /proc/my_status，也可以使用命令去測試驅動程序；

2.2 The types of resource managers

一般可以將資源管理器分爲兩類：

• 設備資源管理器
• 文件系統資源管理器

1. 設備資源管理器
   設備資源管理器只在文件系統中創建單個文件條目，每個條目都向進程管理器註冊，每個名稱通常代表一個設備。

2. 文件系統資源管理器
   文件系統資源管理器會向進程管理器註冊一個掛載點，掛載點是註冊到進程管理器中的路徑的一部分。路徑的其他部分由文件系統資源管理器管理。比如掛載點是/mount，路徑是/mount/home/thomasf，由進程管理器來標識/mount，而由文件系統管理器來標識home/thomasf。

2.3 Communication via native IPC

當一個資源管理器綁定好對應的路徑名後，它便可以收到客戶端的請求信息了，比如io_open、io_read等。
客戶端程序與資源管理器之間的所有通信都是通過本機IPC消息傳遞完成的，它有許多獨特的功能：

• 定義良好的應用程序接口，客戶端與資源管理器分工明確；
• 資源管理器的接口簡單，與OS交互也是通過本地IPC，不需要擔心其他模塊的影響；
• 網絡傳遞，底層原生IPC機制本質是網絡分佈式的，程序可以無縫的訪問網絡中其他節點的資源；

所有QNX Neutrino的設備驅動程序和文件系統都是作爲資源管理器實現的，這意味着“原生”QNX Neutrino設備驅動程序或文件系統能做的一切，用戶編寫的資源管理器也能做到。

3. Resource manager architecture

資源管理器的核心如下：

initialize the dispatch interface
register the pathname with the process manager
DO forever
    receive a message
    SWITCH on the type of message
        CASE io_open:
            perform io_open processing
            ENDCASE
        CASE io_read:
            perform io_read processing
            ENDCASE
        CASE io_write:
            perform io_write processing
            ENDCASE
        .   // etc. handle all other messages
        .   // that may occur, performing
        .   // processing as appropriate
    ENDSWITCH
ENDDO

資源管理器架構包括三部分：

1. 創建一個通道，以便客戶端程序可以連接到資源管理器上，併發送消息；
2. 資源管理器需要向進程管理器註冊路徑名，以便能在對該特定的路徑名請求打開時，能解析到該資源管理器；
3. 接收並處理消息；
   每個資源管理器都需要消息處理功能（上文代碼中的switch/case部分），QNX Neutrino提供了一組庫函數來方便的處理這個功能，當然也能處理其他關鍵功能。

3.1 Message types

資源管理器會收到兩種類型的消息：

• connect messages，客戶端在操作路徑名時（比如io_open）時會發送連接消息，這可能會涉及到權限檢查（客戶端是否有打開設備的權限），併爲該請求設置上下文；
• I/O messages，基於上下文（客戶端和資源管理器之間創建的）來發送I/O消息，比如io_read；

3.2 The resource manager shared library

QNX Neutrino提供了一下共享庫，可以讓資源管理器編寫變得相對簡單一點。

1. 自動默認消息處理
   當資源管理器不想處理某些消息時，可以使用默認的動作，目前有兩個級別的默認動作：

• 給客戶端返回ENOSYS，表明不支持特定功能；
• iofunc_*()共享庫，允許資源管理器自動處理多種功能；
  由於資源管理器接收的大量消息都處理一組公共屬性，iofunc_*共享庫允許資源管理器自動處理stat()、chmod()、chown()、lseek()等函數，無需再編寫額外代碼。有三個主要的結構需要考慮：
• context，保存每次打開時使用的數據，例如文件中的當前位置（lseek()偏移量）；
• attributes structure，保存每個設備的數據，例如設備所有者的用戶和組ID、最後修改時間等；

• mount structure，對於文件系統管理器來說，需要mount structure，包含對整個掛載設備都可全局訪問的數據項；

   

  A resource manager is responsible for three data structures

當有多個客戶端程序在特定資源上打開多種設備時，數據結構如下圖：

 

Multiple clients opening various devices

iofunc_*()默認函數的運行假設是：使用了context塊和attribute結構的默認定義，這是一個可靠的假設，原因有二：

• 默認的context和attribute結構爲大多數應用程序提供了足夠的信息；
• 如果默認結構沒有包含足夠的信息，它們可以封裝在自定義的結構中；
  在自定義數據結構時，需要把attribute的結構放在前邊，以便iofunc_attr_t *()函數能使用，如下圖：

  圖片.png

1. 資源管理器共享庫提供了跟蹤open()/dup()/close()消息的默認處理函數，並且只對最後一個close執行操作；

2. 多線程處理
   QNX Neutrino提供多線程，可以基於這個來構造資源管理器，多個線程等待消息並同時處理它們。資源管理器共享庫不僅可以跟蹤創建的線程數量和等待線程的數量，還負責維護最佳的線程數量。

3. dispatch功能
   操作系統提供一套`dispatch*函數集，可用於：

• 給需要多種消息類型的資源管理器和客戶端提供一個公共阻塞點；
• 給沒有綁定到資源管理器的消息類型提供靈活的接口；
• 在線程中將阻塞和處理代碼解耦合；

1. Combine messages
   QNX支持將IO消息或connect消息組合成一個消息，從而進行一些類似原子性的操作。比如通過將io_lseek和io_read消息組合成一個消息，資源管理器在收到這個消息時，readblock()函數就會允許線程去原子性的執行lseek()和read()操作。