系列gdev-masterNVIDIA/nouveau 用戶態(tài) GPGPU 運行時從 C/C 到 Rust 的移植工程形狀不是性質收在「綠照到的是哪部分」這個問題上還留了一條本機證否不了的口子libdrm 的版本落差只能上機當天量。這一篇就是那一天的實錄走完——答案是一個帶腳注的「能」。先把結論釘在桌上每個數(shù)都給口徑數(shù)值口徑真機 gate6/6 用例 stdoutstderrrc 逐字節(jié)一致比對副本剔除 6 行已登記基線插樁后§三用例構成見 §四真算力覆蓋首跑 3/6 → 當晚補跑后 5/6上 GPU 真算并回拷的用例數(shù)§四、§五倉庫448 個 commit138 個.rs/ 90,636 行git rev-list --count HEADfind rust/gdev-rs -name *.rs -not -path */target/*行數(shù)同條加 -exec cat {} 單測938 全綠cargo test --workspace --lib09-23 體檢真跑的讀數(shù)不是沿用值一、上機前的最后兩步出「.so 可交」的結論之前還有兩步收尾都記在案門-48 整單收口 最終見證48 鍵 93 條判據(jù)全部落地對賬 69 48 回填 21 顯式不回填出門清單從干凈 HEAD 重編六步全綠雙庫 sha256 凍結在 MANIFEST最后做了一次「最終見證 PASS」——48 鍵當日全量重掃36 分鐘嚴格判據(jù) S1…S7 全過。結論開發(fā)機段驗證完盡.so可交。發(fā)起檢查第一輪查出四類真問題——最重的一條是49 個提交未推送本地唯一副本覆蓋門-48 全程第二輪換方法深查不采信聲明、直接量原始狀態(tài)cargo test真跑 938 全綠、雙庫 sha 字節(jié)級與 MANIFEST 一致、證偽注入 9/9。順帶把方法論復盤如實入檔第一輪為什么沒看出來——看見了信息、沒看見問題檢查做成了「驗證聲明」而不是「找未聲明的洞」。49 個提交當天推上遠端。二、首查目標機是 oceanProxmox上的 Fedora 18 VMGTX 580 直通。第一件事不是跑是查——按單分四批每批只做「讀取證 登記」批次查到什么首查內核 ?uname -r3.6.10-4.gdev.fc18.x86_64gdev 內核在跑設備 ?C 基線 ?——卡點全在環(huán)境側批次二GPU 直通 ?nouveau.ko在盤上、只是從未modprobe批次三modprobe后card0在C 基線定案其構建腳本userON/uschedOFF與本工程移植裁定逐項吻合批次四三個測試二進制與開發(fā)機同源 ?推送段至此打通產(chǎn)物上機C 基線指紋記下當時口徑 N2 條。三、首跑 5/6gate 首跑?六個用例里 5 處不一致。沒慌按逐文件對讀——.out/.err/.rc兩側全部取回stderr、退出碼六個用例兩側全同數(shù)值memcpy 的14, 17逐字同差異全部且僅是C 側比 Rust 多兩行調試打印func:gdev_raw_dev_open line:227、1guyanqing gdev_launch。這兩行是誰的三路核實一路一命令核哪路結果上游 C 源樹 grep 這兩行零命中目標機上兩份 C 庫strings命中測試二進制零命中? 目標機的 C 基線 上游 C 調試 printf。Rust ≡ 上游 C不一致的是「尺子被人加過字」。這里三條鐵律同時到場不改 C它帶插樁也是當天的尺子、不改 Rust它沒錯、判據(jù)不許為了讓門變綠而改——那就只剩一條路把這兩行已登記的基線插樁從比對副本里剔除字面 行尾錨防誤傷原始輸出一個字節(jié)不動exempt_lines6寫進 GATE-SUMMARY豁免行登記進 RUNBOOK §7。關鍵是下一步要求對豁免規(guī)則本身再來一遍自測三過才上線能消掉 5 處已知差異規(guī)則有效注入一個真差異14, 17改14, 18——仍然紅規(guī)則沒把門弄瞎帶后綴的行不剔行尾錨真的在錨。復跑6/6 用例 stdoutstderrrc 逐字節(jié)一致。設備旁證 5/6 成立——用LD_PRELOAD把/dev/dri/*藏起來輸出必須變不變的那 1 個是matrixadd無參輪設計上就不碰設備屬預期這一天的綠是有信息量的綠。當天章照跑--falsifyrc011 注入、各紅各通道、checkrc0首跑觀測凍成基線deploy_expected/gate.record。四、綠允許寫什么三個腳注「6/6 逐字節(jié)一致」這句話能寫但它帶腳注。六個用例其實折成三疊疊用例綠的含義真算力matrixadd -16、memcpy×2數(shù)值/輸出逐字同3/6錯誤路徑等價madd×2兩側同敗在cuModuleLoad失敗信息與 rc 逐字同設計內早退matrixadd 無參Invalid arguments、rc0兩側同不碰設備腳注一覆蓋首跑的真算力是 3/6——madd 兩個用例兩側一樣地敗在模塊裝載上。錯誤路徑等價也是等價但它不叫真算力這一條當晚就銷掉了§五5/6。腳注二madd 的Test passed驗的是什么madd.c:236的回讀循環(huán)是dummy_c c[idx]——讀了不比。所以 madd 的Test passed證明的是「裝載 → launch → 回拷 → 釋放」這條 API 路徑走得通不證明數(shù)值。它跑的 cubin 還是 3080 機器上新版 nvcc 編的sm_86這份 SASS 在 Fermi 上此測試設計上看不出能不能真跑——照實寫不裝。腳注三計時差異是測試固有的memcpy 打印的是耗時不是數(shù)據(jù)微秒數(shù)每跑必不同byte-exact 要歸一化設計當日未立登記在案目標機沒有 strace序列通道本次未覆蓋——同樣寫明。五、oracle 被換sha 對撞逮住的一天當晚先銷遺留。madd 裝載失敗的根因坐實main.c:13傳的是path.madd.c:97從 cwd 拼./madd_gpu.cubin而 gate 在倉庫根跑 ? 永遠找不到。修法很樸素用例從自己的目錄跑——deploy.sh、device_probe 三處、本地 gate.sh三處一致不一致的話藏設備那一輪 cwd 不同會造出「假設備旁證」。真機補跑madd 兩輪兩側Test passed、rc0全 API 鏈走通Exec 耗時非零C 0.584ms / Rust 0.084ms。真算力 3/6 →5/6。順手把 C 基線指紋從 2 條補滿到 6 條4 條 sha 2 條 LINK 拓撲行更正一處登記目標機build/{lib,cuda}是軟鏈、指入build/release同 inode——一套構建兩條路徑原先登記的「兩套并存」機制說錯了判讀僥幸未受影響更正也是斷言復量過才落筆。然后是這一天真正值得記的事。補跑輪 gate 判紅mismatch9逐文件歸因無一處是 Rust 跑偏計時打印 6 處madd / memcpy 用例固有的計時行腳注三Opened/Closed3 處。后三處把一個事實釘死了gdev_platform.h:65的用戶態(tài)GDEV_PRINT就是無條件fprintf(stderr, …)沒有任何編譯條件受GDEV_DEBUG_PRINT控制的是GDEV_DPRINT? Rust 側的打印p1/api.rs:883是忠實的缺打印的是 C 那邊。而 C 那邊為什么缺基線當天被人換了。push 時 sha 對撞01:30 還在的bc86bec1…15:03 變成了307bb011…exempt_lines6→0舊的調試 printf 沒了但上游無條件打印也不打了 ? 這是一份第三種源狀態(tài)既非上游原物也非首跑那份。這件事的兩層教訓比當天任何一行代碼都值錢指紋只護 push→gate 這個窗口?？鐣挀Q基線指紋管不著——管著的是 GATE-SUMMARY 里sha_lib_c的對撞本輪就是這么逮住的不是理論?！窩 是 oracle」第一次反過來咬oracle 不是天上掉的是人在目標機上編出來的人會重編。尺子自己會變所以量尺子的動作指紋、對撞必須是流程的一部分而不是當天的儀式。操作面同日兩筆也入檔cloudflared「一次連接即僵」用ControlMaster復用一條活連接撐過 push/gate 連發(fā)pkill -f匹配到自己命令行把 shell 殺了兩次——殺/啟分開調用 中括號技巧。產(chǎn)物方面gate 結果目錄收攏進~/gdev-rust-gate/時間戳/并修掉 do_fetch 的一個空串假綠——門-11 同族。六、遺留與下線目標機下線sshNo route to host宿主機上qm start報PCI 0000:01:00.0 already in use by VMID 106——GTX 580 被 VM 106 占著106 不是本方的 VM。留下去的賬都在 STATUS 待辦區(qū)登記oracle 源狀態(tài)對齊待環(huán)境負責人要么恢復上游原物 ? 豁免歸零、純逐字節(jié)綠要么明確「以此版為準」? 3 行進豁免表。在那之前gate 判紅恒為那 3 處.err裁決那兩行[gdev] Opened/Closed字面進豁免同款字面加行尾錨模式自測三過后才上線管線級驗證等機器恢復后的首輪 gate計時打印的 byte-exact 歸一化設計未立真機恢復后的續(xù)跑。但主問題已經(jīng)答完了。plan 序 8 ——「全項目唯一未被回答的問題」——能。項目主體P0–P4 M4至此收口。這一篇的一句話真機上的綠和開發(fā)機上的綠是同一種東西——不是結論是信號。它這一天的信息量被三件事?lián)沃卦O備會變紅的旁證、先自測三過的豁免、對撞就報警的指紋。 上機第一跑 —— 一個帶腳注的「能」
系列gdev-masterNVIDIA/nouveau 用戶態(tài) GPGPU 運行時從 C/C 到 Rust 的移植工程形狀不是性質收在「綠照到的是哪部分」這個問題上還留了一條本機證否不了的口子libdrm 的版本落差只能上機當天量。這一篇就是那一天的實錄走完——答案是一個帶腳注的「能」。先把結論釘在桌上每個數(shù)都給口徑數(shù)值口徑真機 gate6/6 用例 stdoutstderrrc 逐字節(jié)一致比對副本剔除 6 行已登記基線插樁后§三用例構成見 §四真算力覆蓋首跑 3/6 → 當晚補跑后 5/6上 GPU 真算并回拷的用例數(shù)§四、§五倉庫448 個 commit138 個.rs/ 90,636 行git rev-list --count HEADfind rust/gdev-rs -name *.rs -not -path */target/*行數(shù)同條加 -exec cat {} 單測938 全綠cargo test --workspace --lib09-23 體檢真跑的讀數(shù)不是沿用值一、上機前的最后兩步出「.so 可交」的結論之前還有兩步收尾都記在案門-48 整單收口 最終見證48 鍵 93 條判據(jù)全部落地對賬 69 48 回填 21 顯式不回填出門清單從干凈 HEAD 重編六步全綠雙庫 sha256 凍結在 MANIFEST最后做了一次「最終見證 PASS」——48 鍵當日全量重掃36 分鐘嚴格判據(jù) S1…S7 全過。結論開發(fā)機段驗證完盡.so可交。發(fā)起檢查第一輪查出四類真問題——最重的一條是49 個提交未推送本地唯一副本覆蓋門-48 全程第二輪換方法深查不采信聲明、直接量原始狀態(tài)cargo test真跑 938 全綠、雙庫 sha 字節(jié)級與 MANIFEST 一致、證偽注入 9/9。順帶把方法論復盤如實入檔第一輪為什么沒看出來——看見了信息、沒看見問題檢查做成了「驗證聲明」而不是「找未聲明的洞」。49 個提交當天推上遠端。二、首查目標機是 oceanProxmox上的 Fedora 18 VMGTX 580 直通。第一件事不是跑是查——按單分四批每批只做「讀取證 登記」批次查到什么首查內核 ?uname -r3.6.10-4.gdev.fc18.x86_64gdev 內核在跑設備 ?C 基線 ?——卡點全在環(huán)境側批次二GPU 直通 ?nouveau.ko在盤上、只是從未modprobe批次三modprobe后card0在C 基線定案其構建腳本userON/uschedOFF與本工程移植裁定逐項吻合批次四三個測試二進制與開發(fā)機同源 ?推送段至此打通產(chǎn)物上機C 基線指紋記下當時口徑 N2 條。三、首跑 5/6gate 首跑?六個用例里 5 處不一致。沒慌按逐文件對讀——.out/.err/.rc兩側全部取回stderr、退出碼六個用例兩側全同數(shù)值memcpy 的14, 17逐字同差異全部且僅是C 側比 Rust 多兩行調試打印func:gdev_raw_dev_open line:227、1guyanqing gdev_launch。這兩行是誰的三路核實一路一命令核哪路結果上游 C 源樹 grep 這兩行零命中目標機上兩份 C 庫strings命中測試二進制零命中? 目標機的 C 基線 上游 C 調試 printf。Rust ≡ 上游 C不一致的是「尺子被人加過字」。這里三條鐵律同時到場不改 C它帶插樁也是當天的尺子、不改 Rust它沒錯、判據(jù)不許為了讓門變綠而改——那就只剩一條路把這兩行已登記的基線插樁從比對副本里剔除字面 行尾錨防誤傷原始輸出一個字節(jié)不動exempt_lines6寫進 GATE-SUMMARY豁免行登記進 RUNBOOK §7。關鍵是下一步要求對豁免規(guī)則本身再來一遍自測三過才上線能消掉 5 處已知差異規(guī)則有效注入一個真差異14, 17改14, 18——仍然紅規(guī)則沒把門弄瞎帶后綴的行不剔行尾錨真的在錨。復跑6/6 用例 stdoutstderrrc 逐字節(jié)一致。設備旁證 5/6 成立——用LD_PRELOAD把/dev/dri/*藏起來輸出必須變不變的那 1 個是matrixadd無參輪設計上就不碰設備屬預期這一天的綠是有信息量的綠。當天章照跑--falsifyrc011 注入、各紅各通道、checkrc0首跑觀測凍成基線deploy_expected/gate.record。四、綠允許寫什么三個腳注「6/6 逐字節(jié)一致」這句話能寫但它帶腳注。六個用例其實折成三疊疊用例綠的含義真算力matrixadd -16、memcpy×2數(shù)值/輸出逐字同3/6錯誤路徑等價madd×2兩側同敗在cuModuleLoad失敗信息與 rc 逐字同設計內早退matrixadd 無參Invalid arguments、rc0兩側同不碰設備腳注一覆蓋首跑的真算力是 3/6——madd 兩個用例兩側一樣地敗在模塊裝載上。錯誤路徑等價也是等價但它不叫真算力這一條當晚就銷掉了§五5/6。腳注二madd 的Test passed驗的是什么madd.c:236的回讀循環(huán)是dummy_c c[idx]——讀了不比。所以 madd 的Test passed證明的是「裝載 → launch → 回拷 → 釋放」這條 API 路徑走得通不證明數(shù)值。它跑的 cubin 還是 3080 機器上新版 nvcc 編的sm_86這份 SASS 在 Fermi 上此測試設計上看不出能不能真跑——照實寫不裝。腳注三計時差異是測試固有的memcpy 打印的是耗時不是數(shù)據(jù)微秒數(shù)每跑必不同byte-exact 要歸一化設計當日未立登記在案目標機沒有 strace序列通道本次未覆蓋——同樣寫明。五、oracle 被換sha 對撞逮住的一天當晚先銷遺留。madd 裝載失敗的根因坐實main.c:13傳的是path.madd.c:97從 cwd 拼./madd_gpu.cubin而 gate 在倉庫根跑 ? 永遠找不到。修法很樸素用例從自己的目錄跑——deploy.sh、device_probe 三處、本地 gate.sh三處一致不一致的話藏設備那一輪 cwd 不同會造出「假設備旁證」。真機補跑madd 兩輪兩側Test passed、rc0全 API 鏈走通Exec 耗時非零C 0.584ms / Rust 0.084ms。真算力 3/6 →5/6。順手把 C 基線指紋從 2 條補滿到 6 條4 條 sha 2 條 LINK 拓撲行更正一處登記目標機build/{lib,cuda}是軟鏈、指入build/release同 inode——一套構建兩條路徑原先登記的「兩套并存」機制說錯了判讀僥幸未受影響更正也是斷言復量過才落筆。然后是這一天真正值得記的事。補跑輪 gate 判紅mismatch9逐文件歸因無一處是 Rust 跑偏計時打印 6 處madd / memcpy 用例固有的計時行腳注三Opened/Closed3 處。后三處把一個事實釘死了gdev_platform.h:65的用戶態(tài)GDEV_PRINT就是無條件fprintf(stderr, …)沒有任何編譯條件受GDEV_DEBUG_PRINT控制的是GDEV_DPRINT? Rust 側的打印p1/api.rs:883是忠實的缺打印的是 C 那邊。而 C 那邊為什么缺基線當天被人換了。push 時 sha 對撞01:30 還在的bc86bec1…15:03 變成了307bb011…exempt_lines6→0舊的調試 printf 沒了但上游無條件打印也不打了 ? 這是一份第三種源狀態(tài)既非上游原物也非首跑那份。這件事的兩層教訓比當天任何一行代碼都值錢指紋只護 push→gate 這個窗口?？鐣挀Q基線指紋管不著——管著的是 GATE-SUMMARY 里sha_lib_c的對撞本輪就是這么逮住的不是理論?！窩 是 oracle」第一次反過來咬oracle 不是天上掉的是人在目標機上編出來的人會重編。尺子自己會變所以量尺子的動作指紋、對撞必須是流程的一部分而不是當天的儀式。操作面同日兩筆也入檔cloudflared「一次連接即僵」用ControlMaster復用一條活連接撐過 push/gate 連發(fā)pkill -f匹配到自己命令行把 shell 殺了兩次——殺/啟分開調用 中括號技巧。產(chǎn)物方面gate 結果目錄收攏進~/gdev-rust-gate/時間戳/并修掉 do_fetch 的一個空串假綠——門-11 同族。六、遺留與下線目標機下線sshNo route to host宿主機上qm start報PCI 0000:01:00.0 already in use by VMID 106——GTX 580 被 VM 106 占著106 不是本方的 VM。留下去的賬都在 STATUS 待辦區(qū)登記oracle 源狀態(tài)對齊待環(huán)境負責人要么恢復上游原物 ? 豁免歸零、純逐字節(jié)綠要么明確「以此版為準」? 3 行進豁免表。在那之前gate 判紅恒為那 3 處.err裁決那兩行[gdev] Opened/Closed字面進豁免同款字面加行尾錨模式自測三過后才上線管線級驗證等機器恢復后的首輪 gate計時打印的 byte-exact 歸一化設計未立真機恢復后的續(xù)跑。但主問題已經(jīng)答完了。plan 序 8 ——「全項目唯一未被回答的問題」——能。項目主體P0–P4 M4至此收口。這一篇的一句話真機上的綠和開發(fā)機上的綠是同一種東西——不是結論是信號。它這一天的信息量被三件事?lián)沃卦O備會變紅的旁證、先自測三過的豁免、對撞就報警的指紋。