驅動程式執行器負責啟動在驅動程式代管程序環境中執行的執行元件。
使用驅動程式庫執行元件
如要使用驅動程式庫執行元件，元件的資訊清單必須包含類似下列內容的 program 區塊：
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
}
}
驅動程式庫元件的 program 區塊至少需要下列欄位：
runner：這個欄位必須設為字串driver。binary：元件套件中驅動程式庫二進位輸出的路徑。bind：元件套件中已編譯繫結程式的路徑。
選填欄位
除了必填欄位外，驅動程式執行器還接受一組選填欄位，用於指定中繼資料或設定驅動程式庫元件的執行階段環境。
主機代管
如果 colocate 欄位設為字串 true，系統會盡可能將驅動程式庫放在與上層驅動程式相同的驅動程式主機。不過，這只是建議。驅動程式管理員仍可能會將驅動程式庫放在個別的驅動程式代管程序中，例如父項裝置已設定 MUST_ISOLATE。在 DFv1 中，如果父項裝置是複合裝置，驅動程式庫一律會共置，但您仍可透過在複合裝置的主要片段上設定 MUST_ISOLATE 來強制隔離。
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
colocate: "true"
}
}
如未指定 colocate 欄位，其值預設為字串 false。
colocate 與 host_restart_on_crash 欄位互斥。驅動程式庫只能符合其中一項條件。
預設調度員選項
default_dispatcher_opts 欄位提供建立驅動程式庫預設調度工具時使用的選項，例如：
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
default_dispatcher_opts: [ "allow_sync_calls" ]
}
}
這個欄位中的選項會對應至 types.h 檔案中定義的旗標。目前支援的選項包括：
allow_sync_calls：這個選項表示調度器可能不會與其他驅動程式共用 Zircon 執行緒。這項設定可讓驅動程式庫在調度器上進行同步 Banjo 或 FIDL 呼叫，不會發生死結。
預設的調度員排程角色
default_dispatcher_scheduler_role 欄位提供建立驅動程式庫預設調度工具時使用的選項，例如：
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
default_dispatcher_scheduler_role: "fuchsia.graphics.display.driver"
}
}
請確認您指定的排程器角色，與元件透過 fuchsia.scheduler/RoleManager.SetRole FIDL API 傳送的角色相符。
允許的排程器角色
建立新調度員時，allowed_scheduler_roles 欄位會規定允許傳入的 scheduler_role，例如：
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
allowed_scheduler_roles: "fuchsia.graphics.display.driver"
}
}
這可讓驅動程式庫在執行階段建立新的調度器，並指定 "fuchsia.graphics.display.driver" scheduler_role。
VMAR 排程器角色
vmar_scheduler_role 欄位提供分配 VMAR 時使用的選項，例如驅動程式庫對應的選項：
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
vmar_scheduler_role: "fuchsia.graphics.display.driver.vmar"
}
}
請確認您指定的排程器角色，與元件透過 fuchsia.scheduler/RoleManager.SetRole FIDL API 傳送的角色相符。
備用
如果 fallback 欄位設為字串 true，只有在所有基本驅動程式庫套件都建立索引後，這個備用驅動程式庫才會嘗試繫結。此外，如果這個驅動程式庫與節點相符，且非備援驅動程式庫與同一個節點相符，則非備援驅動程式庫會繫結至該節點。
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
fallback: "true"
}
}
如未指定 fallback 欄位，其值預設為字串 false。
下一個 vDSO
如果 use_next_vdso 欄位設為字串 true，驅動程式庫會放入驅動程式主機，並動態連結下一個 vdso。駕駛人也必須將 colocate 設為 true，否則系統會忽略這個欄位。
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
colocate: "true"
use_next_vdso: "true"
}
}
如未指定 use_next_vdso 欄位，其值預設為字串 false。
裝置類別
device_categories 欄位會提供中繼資料，指出驅動程式庫控制的裝置類別，例如：
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
device_categories: [
{ category: "board", subcategory: "i2c" },
{ category: "sensor", subcategory: "temperature" },
]
}
}
這項中繼資料可用於判斷驅動程式庫在認證程序中會接受的測試。如需裝置類別和子類別的完整清單，請參閱 FHCP 架構。
主機在當機時重新啟動
如果驅動程式庫意外停止運作，host_restart_on_crash 欄位會告知驅動程式庫程式架構，應重新啟動驅動驅動程式庫繫結的節點驅動程式代管程序。
包括：
- 驅動程式主機異常終止。
- 驅動程式會在執行時關閉用戶端端點至
fuchsia.driver.framework/Node通訊協定。
由於這會影響驅動程式代管程序，因此只能由主機的根驅動程式庫設定。
根驅動程式庫是建立主機的驅動程式庫。只有在 colocate 欄位設為 false 時，才會發生這種情況。
因此 host_restart_on_crash 和 colocate 互斥。驅動程式庫只能true其中一項。
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
host_restart_on_crash: "true"
}
}
如未指定 host_restart_on_crash 欄位，其值預設為字串 false。
當 host_restart_on_crash 為 false 時，如果驅動程式庫意外停止運作，節點會從驅動程式庫架構的節點拓撲中移除。
Service Connect 驗證
驅動程式庫 SDK 的 DriverBase 會使用 service_connect_validation 欄位，在服務能力連線上執行可用性驗證。
方法是查看磁碟機繫結節點可用的方案，並確保所有 incoming()->Connect() 要求都嘗試連線至有效方案。
在單一父項的情況下，這只是確保節點可以使用服務，因為使用者未指定執行個體時，所有要求都應傳送至 "default" 執行個體。
在複合案例中，這可確保所要求的執行個體名稱和 "default" 執行個體名稱案例，都有來自該上層的相應方案。
如果這些驗證失敗，Connect() 方法會立即傳回 ZX_ERR_NOT_FOUND，而不是建立連線，等到對連線呼叫雙向方法時才失敗。
{
program: {
runner: "driver",
binary: "driver/example.so",
bind: "meta/bind/example.bindbc",
service_connect_validation: "true"
}
}
如未設定這個欄位，系統預設會停用驗證。
其他資訊
如要進一步瞭解驅動程式的繫結方式，請參閱「驅動程式繫結」。