Aros/Developer/IODeviceDriversDev
AOS 在 dos 列表鎖定和解鎖時分別呼叫 Forbid() 和 Permit()。 （在 Guru 書中也提到這是 1.x 相容性“特性”）
目前有以下注釋
/* This came from MorphOS source code, however looks strange.
Commented out but left for reference.
if (dl)
Forbid(); */
刪除註釋或將其放入 #ifdef _mc68000 中，或者不做任何操作？畢竟這是 AOS 半文件化的功能。我認為我們應該在 LDF_WRITE 上呼叫 Forbid()，但在 LDF_READ 上保持開啟。
是時候將處理程式從 DEVS: 移動到 L: 了。現在它們是像 L: 中的 AOS 處理程式一樣的包處理程式。2011 年 6 月底，現在有了 DOS 包，檔案控制代碼和鎖不再是同一件事。像這樣的程式碼
fdesc *desc = __getfdesc(fd);
if (!desc)
{
errno = EBADF;
return -1;
}
return __stat(desc->fcb->fh, sb);
在編譯器/clib/fstat 中需要從檔案控制代碼建立鎖。最好的方法是什麼，NameFromFromFH 然後 Lock？我們是否需要對 clib 的某些部分採用完全不同的方法？有 LockFromFH/DupLockFromFH() 和 OpenFromLock() - 涵蓋了兩個方向。不需要，我們可以在 __stat() 中使用 ExamineFH 和 NameFromFH。
fib_FileName 儲存為 AROS_BSTR。因此，如果定義了 AROS_FAST_BSTR，則它是一個 C ASCIIZ 字串，否則它是一個 BSTR。
由於 fib_FileName 和 fib_Comment 保證對齊 BPTR，因此在 MKBADDR(&fib_Filename[0]) 上使用 AROS_BSTR_* 宏是完全安全的，它會為您封裝所有內容。
建議重寫這兩個 ps/2 匯流排驅動程式，然後對所有需要的延遲使用 timer.device（在程式碼中添加了很多忙等待延遲。尤其是在中斷程式碼中…）。
- 分離序列滑鼠驅動程式。
- 將 PS/2 滑鼠驅動程式與鍵盤驅動程式合併（它們使用相同的低階函式，需要連結在一起，這就是為什麼我
仍然將 x86-64-pc 板支援包連結到 ELF 中）。
在 AmigaOS 3.1 中，應用程式會查詢 printer.device ，它會讀取印表機首選項檔案，並與為該資訊選擇的印表機驅動程式（針對每臺印表機定製）進行通訊，並將資訊提供給應用程式程式。除了參考自己的首選項以進行頁面設定等之外，應用程式程式還會使用印表機裝置提供的某些控制元件來控制實際的印表機驅動程式，並向其提供正確的命令、二進位制點陣圖或 ASCII 文字資料來執行列印作業。我建議從為 AROS 建立標準（類似 ASL）列印支援請求器開始，並開發新的印表機首選項檔案標準和 printer.device，可以很好地整合到 CUPS、Ghostscript 等中，這些專案是當前開發和支援的開源專案。
- 建立一個與 OS31 相容的 printer.device - 該裝置必須呼叫印表機驅動程式中的相應函式，例如 init()、dospecial()、render()、transfer()、density()，並處理各種 CMD 呼叫，例如 CMD_FLUSH、RESET、START、STOP、WRITE、DUMPRPORT、PRTCOMMAND、QUERY、RAWPRINT 等，並呼叫相應的函式，同時也要嘗試使其與 RTG 相容。
- 在其中建立一個後臺任務
- 建立一個驅動程式來測試我的網路印表機
然後新增
- 一個後臺監視器
- 建立首選項應用程式（也許使用 printer.device v44 首選項訊息，目前還不清楚）
- 一個呼叫 Ghostscript 的驅動程式（如果實際的 gs 埠可用）
- 一個用於我的 PS 印表機的驅動程式，並新增對 USB 連結的支援
- 一個用於我的 PCL 印表機的驅動程式（同一個）
- Sonic 的理念：用於列印的圖形裝置上下文
- 一個呼叫其他內容（如 cups 二進位制檔案）的驅動程式
Postscript Text Graphics | | | | PS Encapsulation | | | Ghostscript Core Rendering Section | | +------------------+ | Print Queue | +----+-----+-----+ Printing Section | | | | Net: Par: USB: Ser: (???)
需要支援
頁面設定應包含標準選項（以及使用者可自定義的選項），用於選擇方向、頁面大小和介質型別。 （一個起點是 [www.pwg.org/ipp/index.html IPP]（Internet Printing Protocol）標準文件中列出的那些選項）。
列印選項應有位置選擇要預覽、列印或列印到磁碟作為檔案（全部、當前、範圍）的文件頁面，列印檔案型別可以是 PDF、SVG、PNG、JPEG。它應該有 N-Up、雙面列印、新增作業單、整理功能（例如訂書、打孔、切割（卷軸式介質））的設定。
帶有排隊和作業管理的色彩管理。
實現可以渲染到點陣圖並使用多種不同格式將其提供給印表機的驅動程式，以處理不支援 PCL 或 PS 的低端噴墨印表機，其中許多印表機沒有記錄的協議（例如，您可能需要反向工程 CUPS 驅動程式）。
改進的 hostdisk.device 設計，合併了一些通用程式碼。在 Windows 上實現了對 64 位映像檔案長度的處理。預設情況下使用扁平 LBA，而不是可能不適合的虛擬幾何。
我記得單塊柱面是一個問題。我認為某些分割槽/檔案系統結構至少需要每柱面兩個塊，也許更多。請參閱 Poseidon massstorage.class，我在那裡遇到了這個問題。
我會檢查 Poseidon 程式碼。但是，另一方面，扁平 LBA 地址似乎是唯一合理的選擇，可以與其他已經有一段時間忽略柱面對齊的 OS 共存。我想知道為什麼 AmigaDOS 建立者在任何地方都使用柱面，因為無論是在低階還是高階上，AmigaOS 都使用 LBA 地址。檔案系統只是執行 cyl * sectors * heads。這更有可能是一個 Poseidon 缺陷。
根據 RKM 的 scsi.device 部分，裝置驅動程式本身似乎需要解析 RDB 並生成引導節點，這與當前的 AROS 方法大不相同，後者由“載入程式”負責 RDB 解析。
所以，這裡有一個計劃。它應該更像 AOS，並將導致對 RDB 卷的支援“熱插拔” - 即 RDB CDROM 和 CompactFlash 裝置。因此，基本上，載入程式中遞迴掃描磁碟分割槽表的程式碼將被移動到 partition.library 中的函式中，該函式將從裝置驅動程式呼叫？這聽起來不錯，並且還會消除 mass-storage 類中該程式碼的重複。
一些要點
無分割槽的卷的 DOS 裝置將如何處理？目前，ATA 裝置作為 HDx 啟動，而 ATAPI 裝置作為 CDx 啟動。如果 HD 具有分割槽表，則 HDx 將被刪除並替換為任何擁有 IO 的分割槽。以同樣的方式。如果沒有分割槽，則會建立“引導塊”樣式節點（HD0），否則，您將只獲得分割槽。partition.library 將處理所有塊裝置的 DOS 詳細資訊 - 它們只需要在磁碟更改時呼叫該函式即可。
看來我們大多數檔案系統 *確實* 正確地處理 ACTION_INHIBIT 和 ACTION_DIE（大多是）。
partition.library -------------
- 向 partition.library 新增一個“BOOL MakeDosPartitions(CONST_STRPTR device, IPTR unit)”。
partition.library
- Enumerates through all partitions (RDB or MBR), and MakeDosNode() a list of DOS nodes (dnlist), generating unique DOS device names if needed. (ie "HD0.1" if "HD0" exists)
載入程式已經包含生成 DOS 裝置名稱的程式碼，所以我們更改所用格式之前應該有一個充分的理由。
- If the new partition list doesn't match an old dnlist in the partition.library's current 'everything I've seen since boot' database:
* Calls RemDosEntry() on all DeviceNodes in the old dnlist
for this device/unit (if any).
* Removes all the old dnlist entries from Expansion->Mountlist
* Remember the new dnlist as one seen by partition.library
- But if it *does* match an existing list, use that instead of the new one we just made.
- Call AddBootNode() on all the DeviceNodes in the new list,
with appropriate (bootable > -128, or nonbootable = -128) priorities.
每個可以具有 RDB/MBR/GUID 分割槽的 foo.device ------
- 修改 ata.device、usb massstorage.class 等
- 呼叫 Partition/MakeDosPartitions(..)
on every diskchange event.
trackdisk.device ----
- 使用 DosType = 0 建立 DeviceNode 條目，沒有處理程式，並
DE_BOOTBLOCKs etc. set correctly for a BootBlock style BootNode.
- AddBootNode(5, 0, dn, NULL)
載入程式 ----
初始引導裝置選擇選單（來自 dosboot.resource）現在被移動到這裡，並且可以用於調整 ExpansionBase->Mountlist 中條目的順序，以及其他內容。
由於 partition.library 維護裝置的分割槽到卷的對映，因此我們可以從 strap 中刪除分割槽程式碼。
1）掃描 ExpansionBase->Mountlist，並
* If not a valid BootNode (node type is not NT_BOOTNODE), ignore it.
* If BootNode->bn_Pri == -128 (non-bootable), ignore it.
* If any of the following are true, ignore it:
- (dn = BootNode->bn_DeviceNode ) == NULL
- (fssm = BADDR(dn->dn_Startup)) == NULL
- (de = BADDR(fssm->fssm_Environ)) == NULL
* bootblocks = (de->de_TableSize < DE_BOOTBLOCKS) ? 0 : de->de_BootBlocks;
* If the node is a valid BootPoint node (bootblocks == 0): (m68k only)
- (cd = (struct ConfigDev *)BootNode->bn_Node.ln_Name) != NULL
- (da = cd->cd_Rom.er_DiagArea) != NULL
- (da->da_Config & DAC_CONFIGTIME) != 0
-- If *all* the above is true, then:
if da->da_BootPoint(configDev, register A2 = bn) returns,
then booting from this device failed.
* If the node is a valid BootBlock node (bootblocks > 0): (all archs)
- OpenDevice(fssm->fssm_Device, fssm->fssm_Unit, &io, fssm->fssm_Flags ) == 0
- Read a bootblock as described in the RKM BootBlock section,
and verify that the checksum is correct.
- If de->de_DosType == 0:
* Update the BootNode's de->de_DosType with the DosType in the
bootblock
- If de->de_DosType != bootblock's de_DosType
* Ignore this device, continue to the next one in the Mountlist
- m68k ONLY: Actually call the bootblock code
If the BootBlock's init() routine returns, assume booting from this
device failed.
- non-m68k ONLY: Simulate calling the bootblock code
- InitResident(FindResident("dos.library", BNULL));
2）沒有有效的引導塊？然後嘗試啟動 dos.library，看看是否有任何“DOS 可引導”節點。
* InitResident(FindResident("dos.library", BNULL));
/* If we return here, then DOS couldn't mount a SYS: volume */
3）顯示引導動畫的迴圈，然後返回到（1）
dos.library -----
這裡的主要變化是 dos.library *可能失敗*，並且如果它找不到 SYS: 卷，則可以 *退出*，返回程式碼為 FALSE。
在基本的 DOS 庫初始化之後
1) While ExpansionBase->MountList is non-empty {
* Remove the first entry (highest priority) off of the MountList
* If a valid boot node, try to DeviceProc() it.
* If DeviceProc() succeeds, this is the SYS: node - exit the loop
* Otherwise, add the node to a temporary list (bn_unbootable) }
2) If no SYS: node:
* Re-add bn_unbootable to the Mountlist
* clean up DOS allocated memory
* return FALSE from this init of dos.library - This is safe, as no DOS volumes have been mounted
3) Otherwise, we have a bootable SYS: node!
4) (non-Amiga) If the SYS:AROS.boot file exists and is *NOT* valid for this machine, Intuition up a requester to tell the user about it, and allow the user to reboot or continue into the weeds of danger.
- Since we can't safely dismount SYS: at this time, there's no easy way to handle this case without a reboot.
找到一個分割槽，其中沒有匹配的 AROS.boot 檔案，這不是錯誤條件。我們需要支援 32 位/64 位雙啟動系統。目前，據我所知，這是不可能的。32 位 Exec 不會執行 64 位程式碼，而 64 位 Exec 不會執行 32 位程式碼。ABI 完全不同。
支援這一點將是……至少可以說，一項有趣的任務，超出了本提案的範圍。
5) Add bn_unbootable to the Mountlist - NOTE: The SYS: device node will *not* be in the Mountlist anymore
6) For each node in the Mountlist:
* If a valid bootnode (NT_BOOTNODE and bn_Pri > -128):
- If ADNF_STARTPROC is set, DeviceProc() it.
7) Execute the dosboot.resource
DOSBootResource = FindResource("dosboot.resource")
InitResident(DOSBootResource, 0)
/* If we return from here, ALERT! */
dosboot.resource ----
此資源不再自動啟動。
所有引導選單內容都已移動到“載入程式”
所有安裝都已移動到 dos.library
我們只需要建立初始分配，並啟動 shell。
也許我們也可以把它移到 dos.library 中？
- 建立 "Initial CLI" 程序
Create initial assigns
InitCode(RTF_AFTERDOS, 0)
- This is, I believe, more like AOS, in that the initial
assigns and CLI are up during RTF_AFTERDOS, and
RTF_AFTERDOS code is called in the "Initial CLI" context
Execute S:Startup-Sequence or Shell
- RemTask(NULL);
存在一些“惡意邊緣情況”，只能透過確保所有處理程式能夠正確處理 ACTION_DIE 以及重啟時過時的 FileLocks 和 FileHandles 來解決。
我不確定是否需要 partition.device。已經存在一種機制來處理從一個埠到另一個埠的 USB 驅動器的熱插拔，同時保留卷的鎖和通知請求（我認為兩個埠是否在同一個控制器上並不重要）。它的工作方式與在 AmigaOS 中允許您將軟盤從 DF0: 交換到 DF1: 的機制相同。這已經在 fat-handler 中實現。這裡的想法是建立一個處理所有現有檔案系統的單個程式碼點，而無需讓每個檔案系統鉤入裝置的磁碟更改機制。
如果處理程式收到新訊息（例如嘗試寫入現有檔案控制代碼），它的原始塊 I/O 將轉到該卷的 partition.device 單位，如果 Intuition 不可用，該 I/O 將阻塞（即 WaitSignal()），直到卷重新掛載。
我們所有的處理程式都應該正確支援 ACTION_INHIBIT 和 ACTION_DIE，這樣當卷實際上已被移除時，處理程式不會認為它仍然存在。
或者，partition.library 可以發出一個彈出視窗（例如“卷 BigDog: 不再可用。[等待卷] [將錯誤返回應用程式]”)，並等待卷返回，或者將 I/O 錯誤返回到檔案系統。
無論哪種情況，是的，處理程式可能會保留下來。
如果我們想要大力推動在所有檔案系統中支援 ACTION_INHIBIT，那麼我們不需要 partition.device 代理裝置。..但是，由於它們在不被禁止時將繼續繫結到同一個 Exec 裝置/單位，因此我們仍然需要 partition.device 代理來處理熱插拔分割槽集（因為 USB 記憶棒或 AHCI 熱插拔驅動器可能會移動到不同的單位，甚至不同的 Exec 裝置）。[ACTION_INHIBIT 更好，因為這應該防止在我們嘗試 ACTION_DIE 彈出分割槽集的處理程式時，它們具有開啟的 Locks 或 FileHandles 時，出現“離線”卷的堆積。至少 AFS 似乎能夠恢復它再次找到的卷。] partition.device 代理不需要，只需要在磁碟更改時根據需要自動傳送 ACTION_INHIBIT。
它在 AmigaOS 中是否曾經與離線卷一起使用？是的，這對 AFS 中 DosList 卷管理的實現至關重要。請參閱 afs/main.c 中的 ACTION_INHIBIT: 部分，並跟蹤程式碼路徑。
離線卷有什麼問題？在它們的處理程式死亡後，它們可能會保留下來，並在重新插入時被處理程式的另一個例項採用。fat-handler 和 massstorage.class 是一個很好的概念證明，因為所有這些熱插拔和離線卷都很好地工作（自資料包切換以來，我沒有測試過此功能）。
[是的，即使 ACTION_INHIBIT 正常工作，您也可以透過熱插拔無數個不同的 USB 記憶棒來佔用所有記憶體，但我目前認為這是一個不有趣的邊緣情況。如果它變得有趣，我們應該確保至少 afs-handler 和 fat-handler 能正確處理 ACTION_DIE。]
步驟
[edit | edit source]- 當一個 Exec 塊裝置（例如 trackdisk.device 單位 0）首次掛載時，它被分配一個具有處理程式（例如 FFS）的 Dos 裝置節點（DLT_DEVICE），並且該處理程式知道它將一直連線到 DosEnviron 中指定的 Exec 裝置，直到它收到 ACTION_DIE（例如 trackdisk.device，單位 0（為了簡潔起見，'td-0'）
- 假設插入一張軟盤。此時，td-0 處理程式（FFS）探測軟盤，在檢測到 FFS 磁碟後，為它建立一個新的 DLT_VOLUME，並將卷的 dol_Task 設定為處理程式的 dol_Task。不要認為 FFS 會確定檔案系統是否為 FSS，認為它“假設”它是 - 如果它無法讀取它，它會假設它只是沒有被格式化或已損壞。
- 新的鎖附加到 DLT_VOLUME 的 dol_LockList。（也許是懶載入，但這是理論）。有點像。它們通常只在卷離線（介質被移除）後才附加到 dol_LockList。
- 假設軟盤被彈出。此時，td-0 處理程式（FFS）探測軟盤裝置，發現沒有磁碟存在，並在自身上執行 ACTION_INHIBIT/TRUE。ACTION_INHIBIT 看到一些鎖開啟，將 DLT_VOLUME 的 dol_Task 設定為 NULL，並將 DLT_VOLUME 保留在 DosList 中。或多或少。處理程式透過 Toni 提到的命令收到軟盤不存在的指示。此時，卷的未決鎖將附加到 dol_LockList。
- 如果嘗試對彈出 DLT_VOLUME 上的鎖/檔案控制代碼執行 I/O，Dos 會檢測到 Lock 的 fl_Volumes' dol_Task 為 NULL，並彈出“請插入卷 XXX”請求器。1.0 版本在 DOS 和 FS 之間存在差異。如果 DOS 需要從卷 Vol: 獲取檔案，但發現它不存在，它會要求使用者將其插入任何位置。但如果 FS 試圖在磁碟上定位另一個塊，那麼它會要求將磁碟替換到特定驅動器中。（是的，我認為，它只是說“磁碟”，而不是給出它的名稱，這在你剛完成三次磁碟交換時是一個很大的煩惱）。我不記得隨著時間的推移這是如何改進的，儘管如此。
- 插入一張新的軟盤。td-0 處理程式執行與 (2) 相同的操作。某件事將不得不抑制 DOSFALSE，否則什麼都不會發生。如果 td-0 正在等待重新插入，它現在可能會返回請求的資料。處理程式實際上正在等待 IOHF_MEDIA_CHANGE，並將重新掃描裝置以確定新的卷是什麼，至少 AROS 就是這樣實現的。在 AROS 中，探測是在介質插入時在 FFS 處理程式本身中完成的。據我所知，AOS 也做了同樣的事情。
- 最初在 td-0 上的軟盤現在插入到 td-1 中。探測後，td-1 處理程式在 DosList 中找到相同的卷，並將卷的 dol_Task 設定為 td-1 的 dol_Task。原始卷現在可用。是的。此外，td-1 處理程式從 dol_LockList 獲取卷的鎖。對 DOS 可用，也就是說。您可以再次開啟該捲上的檔案。如果 td-0 在它上面打開了檔案，它會繼續要求重新插入它（除非 AOS 或 AROS 改進了這一點）。處理程式使用裝置驅動程式的 TD_ADDCHANGEINT/TD_REMCHANGEINT（舊程式碼使用 TD_REMOVE，或者在最壞的情況下輪詢）i/o 命令來檢測介質更改。
基本總結是，DOS 裝置節點繫結到該裝置，持續時間為裝置節點的生命週期（直到它收到 ACTION_DIE），並且它管理它看到的任何卷的生成、檢測、彈出和復活，_在_它的_檔案系統_型別_中，_對於_那個_exec_裝置_。
如果是這樣，我認為這個模型崩潰的地方在這裡
1) 當一個 Exec RDB 可用的塊裝置（例如 ata.device 0）第一次被看到時，會掃描分割槽，併為每個分割槽建立 DOS 裝置，並分配處理程式。每個處理程式都繫結到 Exec 裝置、單位和由它們的 DosEnviron 向量指定的塊範圍。
2) 每個 DLT_DEVICE 都期望能夠與其底層 Exec 裝置通訊，直到它收到 ACTION_INHIBIT 或 ACTION_DIE。
3) 現在假設多個分割槽已經建立了它們的 DLT_VOLUMEs，我們對一些分割槽有一些開啟的鎖，而其他分割槽沒有鎖。
4) ata-0 裝置被彈出。每個現有的 DOS 裝置處理程式將收到 IOHF_MEDIA_CHANGE 事件，並檢測到沒有介質存在，就像情況 4 一樣，將它們的卷設定為解除安裝或“不可用”。它們不應該收到 MEDIA_CHANGE；它們應該收到 INHIBIT。更改的介質不是它們的；它們的介質消失了，因為它們所在的介質發生了變化。與 diskfiles 相比：您已經從 USB 記憶棒掛載了一個磁碟檔案。您拔出記憶棒；磁碟檔案不會突然插入不同的卷，它只是無法再訪問它的卷。將卷 AOSDMS: 重新插入裝置 DFile1: 中。
第 1 到 4 點是正確的，但在第 4 步中可能會採取其他步驟，具體取決於我們正在談論的驅動器型別。假設我們正在談論一個在熱插拔介面上的硬碟驅動器，例如典型的 USB 硬碟或快閃記憶體驅動器。對於 USB，第 4 步對應於 HD 的 USB 插頭從系統中移除。所有使用 HD 的處理程式都將收到 ACTION_DIE。那些具有未決鎖的處理程式將在死亡之前將它們放到它們的卷的 dol_LocksList 中。處理程式消失後，已移除 HD 的 Exec 塊裝置將被銷燬。
如果我們認為處理程式在沒有開啟的鎖時返回 ACTION_INHIBIT 或 ACTION_DIE 時返回 DOSFALSE 是一個錯誤。
或者，這是一個更強的要求，即（只要沒有正在進行的 I/O）Dos 裝置處理程式應該始終正確處理 ACTION_INHIBIT 和 ACTION_DIE，並將它們的鎖遷移到離線卷，並且新的處理程式應該能夠在卷再次聯機時恢復這些鎖？
如果有活動 I/O，並且處理程式針對動作 ACTION_INHIBIT 和 ACTION_DIE 返回 DOSFALSE，那麼處理程式應該保留下來，並等待裝置重新插入，對嗎？
5) 插入一個新的 MBR 裝置。現有的 DOS 處理程式仍然分配給舊的分割槽佈局，看到 OHF_MEDIA_CHANGE，並嘗試在舊的範圍內探測新磁碟上的新卷。希望它們不會找到任何。新的 MBR 卷在哪裡插入？如果它是另一個 USB HD，新的處理程式將被設定，就像之前的 RDB HD 一樣。RDB 的處理程式已經消失，因此它們不會造成任何麻煩。新的 MBR 卷，位於與舊卷相同的物理熱插拔插槽中（裝置和單位）。Exec 裝置需要在重新插入時重新掃描分割槽，對嗎？並且 *不* 將 IOHF_MEDIA_CHANGE 傳遞給任何“陳舊”的處理程式，直到它已驗證這些處理程式與它們開啟的原始 RDB 相匹配，對嗎？它們沒有看到磁碟更改，新卷的插入將為每個新分割槽建立新的 DOS 裝置。這裡確實存在一個問題，即我們是否想要 Action_Die 並重用裝置號。這兩種方法可能都有優點。
所以...現在怎麼辦？ata-0 裝置應該重新掃描以查詢新的分割槽嗎？是的。其他任務/處理程式？
舊的 Dos 裝置應該保留下來（ACTION_INHIBITed），直到我們看到一些看起來像舊 RDB 的東西嗎？在我上面描述的情況下（USB HD）不是這樣。更有趣的情況類似於接受分割槽可移動介質的 DVD-RAM 驅動器。IMHO，當分割槽介質被移除時，處理程式應該收到 ACTION_DIE，但 Exec 塊裝置會保留下來。這可能也適用於 SATA HD。是的，至少那些被禁止的。關於重用數字的問題出現了。如果我們重用了那些沒有鎖的數字，那麼重新插入記憶棒可能會為它們提供不同的裝置號。
如果它們不抑制怎麼辦？但我們最好不要拉動控制桿，因為它們正在忙著寫入它。我們應該從舊的 RDB 中 ACTION_DIE DOS 裝置嗎？是的，因為它們是為不再存在的情況動態建立的。不，因為我們可能希望重新插入該卷。我們必須權衡一下。有人知道參考嗎？
如果它們不消失怎麼辦？那麼該作業系統元件中存在錯誤。