什麼是Framework呢? 這邊就簡單說一下整個EFI framework架構。
我個人猜想，當初Intel 開發EFI其實只是為了要擴充BIOS的功能，因為在Legacy BIOS的年代，很多的東西都沒有模組化，因此當硬體或是Platform有比較大的變動的時候，對於整個BIOS開發的時間就會延長，那種感覺就好像是你每次都要對一個新的硬體重新寫一次你的BIOS程式碼，很沒有效率。
另外在Legacy BIOS年代，所有的BIOS程式碼的開發幾乎都是不同的BIOS vendor與Chipset 廠商ㄧ同合作，因此不同家的BIOS Vendor對於相同Chipset 廠商所寫出來的程式碼的穩定度就會不同，這對於 Intel 來說就等於要多花好幾倍的時間去跟不同BIOS Vendor 來討論以及處理問題。
因此，假如Intel 能夠把底層的BIOS程式碼變成模組化容易抽換，那麼BIOS在開發的過程中就會快速以及方便許多，而這種概念就像是Windows裡面的HAL 層的概念，簡單說在Windows系統中實際存取硬體是透過ㄧ個叫做HAL介面的處理，所以當Windows想要在不同的硬體上執行的時候，他只要把HAL的介面換成新的硬體的處理方式就可以了，而在Windows可以不用再重新改寫，例如你把Windows拿到Apple上面去執行，對於微軟的工程師來說，只要把HAL從新改寫就可以了。
而EFI的Framework 就像是HAL，Intel 本身提供了一些Protocol以及一些Lib來存取他們的硬體，而這一層就叫做Framework。對於Intel來說，不管你是哪一家的BIOS Vendor就不會再出現A廠商存取Intel Chipset有問題而B廠商不會，因為最底層都是Intel 自己負責。
而建構在Framework 上的一些功能就是各家BIOS Vendor自己去負責，感覺就像我之前說的，Inetl 留下一些地方給BIOS Vendor填寫他們的程式碼，然後BIOS Vendor在留下一些地方給OEM/ODM BIOS填寫ㄧ些程式碼，彼此關係就是一層一層環環相扣。
這邊還要提到EFI Framework 除了前面說的那些之外，他還提供了一些Boot Flow的控制，這就像是說從Power On--->POST--->Boot to OS的一些流程的控制也是由這個Framework 提供，感覺就像是你寫了一個main{}，而裡面的FunA()/FunB()/FunC() 的先後順序的執行你也都寫好了，之後FunA() 內要填什麼樣的子程式碼就屬於BIOS Vendor跟OEM/ODM BIOS自己決定了。
//--------------------------------------------------
// EFI Framework 的概念與C語言對應的示意圖
//--------------------------------------------------
#include
main() <--Intel 提供的Boot Flow
{
Dispatch FunA(); <--SEC
Dispatch FunB(); <--PEI
Dispatch FunC(); <--DXE
Dispatch FunD(); <--BDS
...
}
EFI Framework還有另一個優點就是移植性高，例如Intel 可以把整個EFI Framework概念移到嵌入式系統上去實做BIOS，這樣子他們能夠開發的市場就會越來越大。
前面提到這些都是Intel提供的EFI Framework，那麼AMD/其他廠商怎麼辦? 對，我也在想這個問題，由上面的說法可以看出Intel 的野心，他想把原本BIOS Vendor做的事情自己拿來做，為了不讓人家知道太多Chipset內的秘密，他自己寫Chipset的函數並做成Framework給BIOS vendor使用，所以我個人在思考幾個問題：
a) 假設不同 BIOS Vendor 都使用相同的函數的情況下，彼此的優缺點是不是只剩下誰提供的OEM/ODM Features比較多 ?
b) 假設不同 BIOS Vendor 都使用相同的Framework下，當底層換成AMD或是其他廠商後，彼此的優缺點是不是只剩下誰對不同廠商的支援度比較高，市場佔有率就比較高?
c)假設OEM/ODM BIOS 都使用相同的Framework後，開發時間縮短相對的被取代的性質是否也相對提高?
d) Others..
以上大致上就是個人對於EFI Framework 的一些理解跟想法，如有誤請先進不吝指正，謝謝!
