英文練習

The OS loader and drivers should not depend on these types of protocols because they are not guaranteed to be present in every EFI-compliant system.

OS loader(作業系統載入器)與驅動程式(EFI Driver)不應該依存protocols的型別，因為它並不保證會出現在每一種兼容EFI的系統上。

OS loaders and drivers should depend only on protocols that are defined in the EFI 1.10 Specification and protocols that are required by platform design guides such as Design Implementation Guide for 64-bit Server.

OS loader(作業系統載入器)與驅動程式(EFI Driver)應該只依存有定義在EFI 1.10規範中以及像是Design Implementation Guide for 64-bit Server之類的平台設計手冊中的protocols。

The extensible nature of EFI allows the developers of each platform to design and add special protocols.

EFI的可延展特性可以讓每一個平台的開發者去設計並加入特殊的protocols。

**Using these protocols, they can expand the capabilities of EFI and provide access to proprietary devices and interfaces in congruity with the rest of the EFI architecture.

**使用這些protocols可以擴充EFI的性能，以及提供存取專有的裝置與介面的能力。

Because a protocol is “named” by a GUID, no other protocols should have that same identification number.

因為protocol是用GUID所命名的，所以不會有其他的protocols會有重複的ID號碼。

Care must be taken when creating a new protocol to define a new GUID for it.

要注意，當在創建新的protocol時，要定義新的GUID它。

EFI fundamentally assumes that a specific GUID exposes a specific protocol interface.

EFI基本假設特殊的GUID會顯露出特殊的protocol介面。

Cutting and pasting an existing GUID or hand-modifying an existing GUID creates the opportunity for a duplicate GUID to be introduced.

剪貼目前現有的GUID或是手動修改現有的GUID會造成產生相同的GUID的機會。

A system containing a duplicate GUID inadvertently could find the new protocol and think that it is another protocol, crashing the system as a result.

系統不小心包含重複的GUID，會發現這個新的protocol會被認為是其他的protocol，結果會導致系統崩潰。

For these types of bugs, finding the root cause is also very difficult.

對於這樣的錯誤，要找出根本原因也是非常困難的。

The GUID allows for naming APIs without having to worry about namespace collision.

GUID允許名命APIs不需考濾到命名空間衝突的問題。

In systems such as PC/AT BIOS, services were added as an enumeration.

在一些像是PC/AT BIOS的系統上，系統服務的增加就如同列舉項目一樣。

For example, the venerable Int15h interface would pass the service type in AX.

例如：Int15h介面會傳遞在AX中的系統服務型別。

Since no central repository or specification managed the evolution of Int15h services, several vendors defined similar service numbers, thus making interoperability with operating systems and pre-OS applications difficult.

由於沒有中央資料庫或是規範管理Int15h系統服務的發展(會有幾個供應商定義相似的系統服務)，使得OS與pre-OS應用程式之間的交握很困難。

Through the judicious use of GUIDs to name APIs and an association to develop the specification, EFI balances the need for API evolution with interoperability.

藉由正確的使用GUID去命名API，並且由工會去發展規範，EFI可以去平衡API的發展與互用性。

英文練習

Not all protocols are defined in the EFI 1.10 Specification.

並非所有的protocols(通訊協定)都定義在EFI 1.10規範中。

The EFI Developer Kit (EDK) includes many protocols that are not part of the EFI 1.10 Specification.

EDK中就包含了許多不屬於EFI 1.10規範的protocols(通訊協定)。

These protocols provide the wider range of functionality that might be needed in any particular implementation, but they are not defined in the EFI 1.10 Specification because they do not present an external interface that is required to support booting an OS or writing an EFI driver.

這些protocols(通訊協定)提供了廣泛的功能，可能被用在一些特殊的實做中，但是這些protocols(通訊協定)並沒有被定義在EFI 1.10規範中，因為他們沒有提供支援開機到OS或撰寫驅動程式(EFI Driver)所需的外部介面。

The creation of new protocols is how EFI-based systems can be extended over time as new devices, buses, and technologies are introduced.

protocols(通訊協定)所創造的是以EFI為基礎的系統如何隨著時間擴充功能，隨著新的裝置、匯流排與技術的引進。

For example, some protocols that are in the EDK but not in the EFI 1.10 Specification are:

例如，一些存於EDK但是不屬於EFI 1.10規範的protocols(通訊協定)：

■ Varstore – interface to abstract storage of EFI persistent binary objects.

變數儲存器 - EFI持續二進位物件的抽象儲存體介面。

■ ConIn – service to provide a character console input.

控制台輸入 - 系統服務所提供的控制台輸入字元的功能。

■ ConOut – service to provide a character console output.

控制台輸出 - 系統服務所提供的控制台輸出字元的功能。

■ StdErr – service to provide a character console output for error messaging.

標準錯誤 - 系統服務所提供的控制台輸出錯誤訊息字元的功能。

■ PrimaryConIn – the console input with primary view.

主要控制台輸入 - 控制台輸入與主要視點。

■ VgaMiniPort – a service that provides Video Graphics Array output.

VGA小型輸出埠 - 系統服務所提供的VGA輸出。

■ UsbAtapi – a service to abstract block access on USB bus.

UsbAtapi - 系統服務所提供的USB抽象區塊傳輸。

■ The EFI Application Toolkit also contains a number of EFI protocols that may be found on some platforms, such as,:

■ PPP Deamon – Point-to-Point Protocol driver.

PPP Deamon - 點對點通訊驅動程式

■ Ramdisk – file system instance on a Random Access Memory buffer.

Ramdisk - 在RAM中的檔案系統。

■ TCP/IP – Transmission Control Protocol / Internet Protocol.

英文練習

Figure 2.3 shows a single handle and protocol from the handle database that is produced by an EFI driver.

圖2.3 所顯示的是在handle database(系統資源資料庫)中的一個由驅動程式(EFI Driver)所產生的handle與protocol。

The protocol is composed of a GUID and a protocol interface structure.

protocols(通訊協定)是由GUID與protocol介面結構所組成的。

Many times, the EFI driver that produces a protocol interface maintains additional private data fields.

許多時候，產生protocol(通訊)介面的驅動程式(EFI Driver)會負責維護額外的私有資料欄位。

The protocol interface structure itself simply contains pointers to the protocol function.

Protocol(通訊)介面結構本身，僅僅包含指向protocols(通訊協定)函式的指標。

The protocol functions are actually contained within the EFI driver.

protocols(通訊協定)函式實際上是被放在EFI驅動程式中。

An EFI driver might produce one protocol or many protocols depending on the driver’s complexity.

驅動程式(EFI Driver)可能會產生一個或一個以上的protocols(通訊協定)，這取決於驅動程式(EFI Driver)的複雜度。

Note:

1. 每一個Handle之下可以掛載多個Protocol。

2. 每一個Protocol是用GUID做識別。

3. 每一個Protocol是由函式指標與私有變數所組成的，可視為用C語言實做C++的類別，Protocol就是虛擬函式表。

4. Protocol中的函式指標所指的就是在EFI Driver中實做的各種函式。

隨筆

今天突然讓一個正妹請吃飯，驚喜之餘，內心是開心的。嗯...我交到一個好朋友。

英文練習

Protocols(通訊協定)

The extensible nature of EFI is built, to a large degree, around protocols.

EFI drivers are sometimes confused with EFI protocols.

驅動程式(EFI drivers)常常會跟通訊協定(EFI protocols)混淆。

Although they are closely related, they are distinctly different.

雖然他們是密切相關，但是它們還是有清楚的不同。

An EFI driver is an executable EFI image that installs a variety of protocols of various handles to accomplish its job.

驅動程式(EFI drivers)是一種可執行的映像檔(EFI image)，它安裝了不同handles中不同的通訊協定(protocols)，來完成他們的工作。

An EFI protocol is a block of function pointers and data structures or APIs that have been defined by a specification.

通訊協定(EFI protocol)可視為函式指標與資料結構組成的資料區塊，或是由EFI規範所定義的APIs。

At a minimum, the specification must define a GUID.

至少，這個規範必須定義GUID。

This number is the protocol’s real name; boot services like LocateProtocol uses this number to find his protocol in the handle database.

這個數值就是通訊協定(protocol)的真實名稱；開機時期系統服務(boot services)像是LocateProtocol()函式就是使用此數值去搜尋在(handle database)中的通訊協定(protocol)。

The protocol often includes a set of procedures and/or data structures, called the protocol interface structure.

通訊協定(protocol)通常會包含程式集與資料結構，而被稱為通訊介面結構(protocol interface structure)。

The following code sequence is an example of a protocol definition from section 9.6 of the EFI 1.10 Specification.

下列的程式碼是擷取自EFI 1.10規範書中第9.6章節中定義通訊協定(protocol)的範例。

Notice how it defines two function definitions and one data field.

注意到它定義了兩個函式與一個資料欄位。

英文練習

Figure 2.2 shows the different types of handles that can be present in the handle database and the relationships between the various handle types.

圖2.2所顯示的是存在於(handle database)中不同類型的handles與它們之間的關聯性。

All handles reside in the same handle database and the types of protocols that are associated with each handle differentiate the handle type.

所有的handles存在於相同的(handle database)中，而protocols的類型是取決於每個handle中不同的handle類型。

Like file system handles in an operating system context, the handles are unique for the session, but the values can be arbitrary.

如同OS環境中的檔案系統handles一樣，handles在此期間是獨一無二的，但是數值本身是多變的。

Also, like the handle returned from an fopen function in a C library, the value does not necessarily serve a useful purpose in a different process or during a subsequent restart in the same process.

而且，在C函式庫中的fopen()函式所回傳的handle，這個值未必可運用在不同的程序，或是隨後重新啟動的相同程序中。

The handle is just a transitory value to manage state.

handle只是一種用於管理狀態的臨時數值。

英文練習

Handle Database(系統資源資料庫)

The handle database is composed of objects called handles and protocols.

handle database(系統資源資料庫)是由被handles(資源控制)與protocols(通訊協定)呼叫的物件所組成。

Handles are a collection of one or more protocols, and protocols are data structures that are named by a GUID.

handles(資源控制)是由一個(含)以上的protocols(通訊協定)所組成，而protocols(通訊協定)則是用GUID所命名的資料結構體。

The data structure for a protocol may be empty, may contain data fields, may contain services, or may contain both services and data fields.

protocols(通訊協定)的資料結構內容可能是空的、或是包含資料欄位、或是包含系統服務，也可能同時包含系統服務與資料欄位兩者。

During EFI initialization, the system firmware, EFI drivers, and EFI applications create handles and attach one or more protocols to the handles.

在EFI初始化的過程中，系統韌體、驅動程式(EFI drivers)與應用程式(EFI applications)會建立handles(資源表)，並將一個以上的protocols(通訊協定)加入此handles(資源表)中。

Information in the handle database is global and can be accessed by any executable EFI image.

handle database(系統資源資料庫)中的資訊是公開的，而且任何可執行的EFI映像檔(EFI image)都可以存取。

The handle database is the central repository for the objects that are maintained by EFI-based firmware.

handle database(系統資源資料庫)是一種EFI基礎韌體所維護的物件儲存中心。

The handle database is a list of EFI handles, and each EFI handle is identified by a unique handle number that is maintained by the system firmware.

handle database(系統資源資料庫)也可視為EFI handles(資源控制)的列表，每一個handles(資源控制)是利用系統韌體所維護的handle number(系統資源標號)作為標示號，以避免重複。

A handle number provides a database “key” to an entry in the handle database.

Handle number(系統資源標號)提供了資料庫的鍵值，給在handle database(系統資源資料庫)中的進入點函式。

Each entry in the handle database is a collection of one or more protocols.

每一個在handle database(系統資源資料庫)的進入點函式都是由一個(含)以上的protocols(通訊協定)所組成的。

The types of protocols, named by a GUID, that are attached to an EFI handle determine the handle type.

由GUID做命名的protocols(通訊協定)的類別，是取決於EFI handles(資源表)所決定的handle type。

An EFI handle may represent components such as the following:

EFI handles(資源表)所象徵的組件如下：

■ Executable images such as EFI drivers and EFI applications

可執行的映像檔，如：EFI驅動程式與EFI應用程式。

■ Devices such as network controllers and hard drive partitions

設備，如：網路控制器與硬碟分區。

■ EFI services such as EFI Decompression and the EBC Virtual Machine

EFI系統服務，如：EFI解壓縮程式(EFI Decompression)與EBC虛擬機(EBC Virtual Machine)。

Figure 2.1 below shows a portion of the handle database.

圖2.1所示為handle database(系統資源資料庫)的一部分。

In addition to the handles and protocols, a list of objects is associated with each protocol.

除了handles(資源表)與protocols(通訊協定)的關聯之外，物件列表會被每一個protocols(通訊協定)連結。

This list is used to track which agents are consuming which protocols.

這個列表是用於追蹤正在使用此protocols(通訊協定)的物件。

This information is critical to the operation of EFI drivers, because this information is what allows EFI drivers to be safely loaded, started, stopped, and unloaded without any resource conflicts.

此資訊是驅動程式(EFI drivers)運行的關鍵，因為這樣可以允許驅動程式(EFI drivers)被安全的載入、開始、停止與卸載而不會造成系統資源的衝突。