ioctl
此條目可參照英語維基百科相應條目來擴充。 |
在計算中,ioctl 是對裝置特定的輸入/輸出操作和其他不能用常規系統呼叫表達的操作的系統呼叫。 它需要一個指定請求代碼的參數; 呼叫的效果完全取決於請求代碼。 請求代碼通常是特定於裝置的。
例如,可以指示物理裝置彈出光碟的 CD-ROM 裝置,則驅動程式將提供 ioctl 請求代碼來執行此操作。 與裝置無關的請求代碼有時用於讓使用者空間訪問僅由核心系統軟體使用或仍在開發中的核心功能。 ioctl 系統呼叫以該名稱首次出現在 Unix 版本 7 中。 大多數 Unix 和類 Unix 系統都支援它,包括 Linux 和 macOS,但可用的請求代碼因系統而異。Microsoft Windows 在其 Win32 API 中提供了一個類似的函式,名為「DeviceIoControl」。
背景
傳統的作業系統可以分為兩層,使用者空間和核心。 文字編輯器等應用程式代碼駐留在使用者空間,而作業系統的底層設施(如網路堆疊)駐留在核心中。 核心代碼處理敏感資源並實現應用程式之間的安全性和可靠性屏障; 因此,作業系統會阻止使用者模式應用程式直接訪問核心資源。 使用者空間應用程式通常通過系統呼叫向核心發出請求,其代碼位於核心層。
系統呼叫通常採用「系統呼叫向量」的形式,其中用索引號指示所需的系統呼叫。 例如,exit() 可能是 1 號系統呼叫,而 write() 號是 4。系統呼叫向量然後用於為請求找到所需的核心函式。 這樣,傳統的作業系統通常會向使用者空間提供數百個系統呼叫。
儘管系統呼叫是訪問標準核心設施的權宜之計,但系統呼叫有時不適用於訪問非標準硬體外圍裝置。 必然地,大多數硬體外圍裝置(也稱為裝置)只能在核心中直接定址。 但是使用者代碼可能需要直接與裝置通訊; 例如,管理員可能會在乙太網路介面上組態媒體類型。 現代作業系統支援多種裝置,其中許多裝置提供大量功能。 核心設計者可能沒有預見到其中一些設施,因此核心很難提供使用這些裝置的系統呼叫。
為了解決這個問題,核心被設計成可延伸的,並且可以接受一個額外的模組,稱為裝置驅動程式,它執行在核心空間,可以直接定址裝置。 ioctl 介面是一個單一的系統呼叫,使用者空間可以通過它與裝置驅動程式進行通訊。 裝置驅動程式上的請求根據此 ioctl 系統呼叫進行引導,通常通過裝置控制代碼和請求編號進行引導。 因此,基本核心可以允許使用者空間訪問裝置驅動程式,而無需了解裝置支援的設施,也不需要難以管理的大量系統呼叫。
使用
硬體裝置組態
ioctl 的一個常見用途是控制硬體裝置。例如,在 Win32 系統上,ioctl 呼叫可以與 USB 裝置通訊,或者它們可以發現附加儲存裝置的驅動器幾何資訊。
在 OpenBSD 和 NetBSD 上,bio(4) 偽裝置驅動程式和 bioctl 實用程式使用 ioctl 在類似於 ifconfig 的統一供應商不可知介面中實現 RAID 卷管理。[1][2]在 NetBSD 上,ioctl 也被 sysmon 框架使用。[3]
終端
在面向終端使用者的應用程式中,ioctl 的一種用途是終端 I/O。 Unix 作業系統傳統上大量使用命令列介面。 Unix 命令列介面建立在偽終端 (ptys) 之上,它類比硬體文字終端,例如 VT100s。 使用 ioctl 呼叫,可以像硬體裝置一樣控制和組態 pty。 例如,pty 的窗口大小是使用 TIOCSWINSZ 呼叫設定的。TIOCSTI(terminal I/O control,類比終端輸入)的ioctl函式可以將一個字元壓入裝置流。
參考文獻
- ^ Super User's BSD Cross Reference: /OpenBSD/share/man/man4/bio.4. bxr.su. [2023-01-09]. (原始內容存檔於2022-10-01).
- ^ Super User's BSD Cross Reference: /OpenBSD/sbin/bioctl/bioctl.8. bxr.su. [2023-01-09]. (原始內容存檔於2023-01-09).
- ^ sysmon(4) — system monitoring and power management interface. NetBSD.
An ioctl(2) interface available via /dev/sysmon.