今天為了檢查前天進辦公室跑的測試問題，很早就進來辦公室，居然發現是因為網路的問題而不是我原本想的系統問題？然而最近幾次進辦公室都有用 Wireshark 來檢查 ARP 廣播封包的數量好確保 UEFI 網路可以正常工作，我們公司的人確實大部份都是 WFH，故不像以前有七八十趴的 ARP 廣播封包，況且出問題時是凌晨四點多鐘，我是不相信那時候公司有什麼人啦！但你知、我知、獨眼龍也知 UEFI network stack 本來就只是堪用，實在不建議拿來用在專案上，無奈我只是個細漢，只好一直面對這種跟程式無關的 issue。
說也湊巧，前一天也是為了解決跟我自己程式無關的 issue（UB，嚴格來說是未定義行為），更新了一些 code 來做防衛駕駛，既然前一個測試被中斷了，想說還是先花一點時間來跑測試驗證這個問題好結案，不然真的很阿雜。沒想到中途又一直遇到網路問題，此時又拿出了 Wireshark 來檢查 ARP 廣播封包，發現一樣剩不到 15%，故應該不是廣播封包問題？
在我使出了任何絕招都無效後，正準備發個郵件問一下 IT 公司網路最近是否有異動？但據我之前經驗，除了廣播封包這個問題外，我們 IT 在收到申請網路特殊用途後，其實不太會去改變申請的網路設定，無奈一時又沒有其他想法！
就在這個 moment，我突然想到好幾年前，我們開始一個新專案後，我本來用的 UDK base 似乎也要跟著更新，當初我最後用的是 UDK2018，不然網路就是會有奇怪的問題，此時 Wireshark 看到的現象就是掉封包或是 network stack 有很多奇怪的行為。剛好今年 WFH 時，我並沒有特別準備 UDK2018 來 build 我的網路程式，而是延用另一個 tool 內建的 UDK base，雖然我無法看出是那個版本，但我直覺應該是 UDK2014 左右的 base。
知道問題後並不是就沒事了，我以後要怎樣避免這個 UDK base 的問題？雖然說寫文件可以解決這個問題，但我們公司的專案並沒有很系統的規劃，導致文件散落一地，我想就算我寫了文件，其他人也不見得遇到網路問題就會想到是這個原因而來我寫文件的資料夾找答案（這就是沒有系統規劃專案的壞處，沒有固定的地方來放文件，所以你也不會有事就去找文件）？
本想 Google 看看是否有 UDK base 的相關 define 來做編譯檢查，無奈這是個很冷門的問題，我用英文在網路上找不到答案。
我又試著用 file search 關鍵字的技巧，看能不能硬在 UDK base 裡找到 define，無奈用了 UDK、2018、VERSION 等關鍵字都沒有幫助，因為這個搜尋的結果太多，我不太可能一個一個 review，只能粗略的看一眼但仍然沒有答案。
最後我決定在 edksetup.bat 做手腳，我在檔案開頭加了以下指令：
echo #define UDK2018 > Stdlib\Include\ABC.h
然後我在我程式的 main.c 加了一個 #include <ABC.h> 並寫清楚註解以提醒後人。
因為我只在我公司電腦的 UDK2018 base 加了這個 trick，故當我這個專案被別人用在別的 UDK base 就一定會遇到 compile error，此時他看我的註解就知道問題是什麼，這樣就達到提醒的作用了，因為那個別人也包括未來的我XD
就在寫此文章的同時，又突然想到用 2.7（UEFI_Spec_2_7，目前最新是 2.8）來搜尋，果然在 MdePkg\Include\Uefi\UefiSpec.h 找到一些 defines，故我們可以用 EFI_SPECIFICATION_VERSION 是否等於 0x20046 或是 EFI_2_70_SYSTEM_TABLE_REVISION 這個 define 是否存在，並配合 #error 這個前置處理器語法來觸發 compiler error。
沒有留言:
張貼留言