跳轉到內容

Aros/開發者/文件/資源/檔案系統

來自華夏公益教科書,開放的書籍,開放的世界
Aros 華夏公益教科書提供的導航欄
Aros 使用者
Aros 使用者文件
Aros 使用者常見問題解答
Aros 使用者應用程式
Aros 使用者 DOS Shell
Aros/使用者/AmigaLegacy
Aros 開發文件
Aros 開發者文件
從 AmigaOS/SDL 移植軟體
面向 Zune 初學者
Zune .MUI 類
面向 SDL 初學者
Aros 開發者構建系統
特定平臺
Aros x86 完整系統 HCL
Aros x86 音訊/影片支援
Aros x86 網路支援
Aros Intel AMD x86 安裝
Aros 儲存支援 IDE SATA 等
Aros Poseidon USB 支援
x86-64 支援
Motorola 68k Amiga 支援
Linux 和 FreeBSD 支援
Windows Mingw 和 MacOSX 支援
Android 支援
Arm Raspberry Pi 支援
PPC Power Architecture
其他
Aros 公共許可證

難道 mountlist 不使用基於裝置的處理程式嗎?我的更改沒有影響到它的名稱。您似乎正在解決核心級處理程式與基於檔案處理程式之間的問題,而我的更改則解決了基於裝置處理程式與基於資料包處理程式之間的問題。

駐留處理程式和基於磁碟的處理程式之間不應該有任何區別。如果處理程式是駐留的,則使用駐留的副本。當實現 FileSystem.resource 時,事情會自動按照這種方式進行(Mount 程式支援它)。目前,它們也以這種方式進行,只是原始的基於資料包的處理程式無法駐留(至少在通常情況下)。並且 genmodule 不能使用破折號作為分隔符。我不想在那裡修改 genmodule,我更希望實現 FileSystem.resource 並完全擺脫 CDVDFS 和 SFS 中的自有 IOFS 包裝器。

如果處理程式既是基於檔案的又是基於資料包的,則破折號已經可以用於處理程式。

我知道。但為什麼要保留基於磁碟的處理程式,因為您已經在核心中有了它?為什麼重複?

我發現構建系統不能很好地處理在同一個目錄中同時構建兩個變體。這對我來說是合理的,因為由於不同的 #define 等,目標檔案可能在兩者之間有所不同。

我知道。但沒有必要同時構建兩個版本。我曾經在託管環境中構建了 IOFS 版本用於測試。我只是決定打包“裸”版本,因為它們更小。並證明可以以原始形式使用這些處理程式。

華夏公益教科書