【EDK II】EDK IIの基礎
UEFIの学習，EDKIIによるModule開発を目的として，EDK ||に関する基礎知識などをまとめていきます。内容は随時追加，構成は変更される場合があります。
備忘録としてここに書き留めます。（随時更新，まとまったらGitBookなどに移動予定）
Module，Package，そしてPlatform
Module
Moduleは，最小のコンパイル可能なコードやプレビルドされたバイナリです。
Moduleはソースコードかバイナリのメタデータ(INF)ファイルを含んでいます。
INFファイルは，Moduleがどんなライブラリクラス，Ppi，
GUIDs，Protocols，Pcdsなどの情報を記述するためにビルドシステムに必要となります。
例えば，$WORKSPACE/MdeModulePkg/Universal/Bus/Pci/UhciDxeが，
上述したソースファイルとINFファイルがModuleを構成します。
INFファイルのシンタックスは「EDK II Extended INF Specification」を参照してください。
Package
Packageは0以上のModuleのグループです。
PackageはDECファイルやDSCファイルを含んでいなければなりません。
機能上は，Packageはプロジェクトを論理分割したものです。
Moduleをどこに置くべきか決めるためには，開発者はライセンスやスペックコンプライアンスなどの合理的な判断に依存します。
これらのメタデータファイルやModuleのINFファイルは，
ビルドシステムがオプションに基づいて自動的にMakefileや単一のModuleチップか全体のflashチップを生成します。
DSC，DECファイルのシンタックスについては「EDK II DSC File Specification」や「EDK || DEC File Specification」を参照してください。
Platform
PlatformはPackageにメタファイルを追加した，Packageの特殊なタイプ（呼称）です。
Packageは1つのDSCファイルと，0か1個のFDFファイルを含んでいる必要があります。Flashのアウトプットが欲しい時だけ，FDFファイルを用意する必要があります。
FDFファイルに関しては「EDK || FDF File Specification」を参照してください。
PlatformをEDKからEDK ||への移植方法については「EDK || Platform Port Guide」を参照ください。
Moduleのカスタマイズ
「EDK II User Manual」を使って，Library class/Library instanceとPCDメカニズムの設計目的を理解してください。これらのメカニズムは開発者に対して，ソースコードを変更せずにモジュールをカスタマイズすることを可能にしています。
EDK II 開発のライフサイクル
EDK IIの開発サイクルは，次の４つのフェーズに分割されます。
Phase 1：Packageの作成
PackageはModuleのコンテナです。
開発者はまず最初に，どこにModuleを置くか考えるべきです。
原則としては，IHV/IBVにより新しく開発されるModuleはEDK II core Packageの中に置くべきではありません（例えばMdePkg，MdeModulePkg，IntelFrameworkPkg，IntelFrameWorkModulePkg）。
その一つの理由は，それらのPackageはModule/Platform開発を促進するベースサポート用に作られたものだからです。これらのPackageはBSD licenseなので開発したModuleをオープンソースにするつもりがないなら，core packageの中に入れるべきではありません。
新たなPackageを作るために，開発者はPackageのインターフェースを定義するためにDECファイルを作成する必要があります。インターフェースには下記を含みます。
・他のPackageからのModuleのためのディレクトリ
・GUIDの値
・Protocol GUIDの値
・PPI GUIDの値
・このPackageによりできるPCDエントリの宣言
Phase 2：メタデータと基本的な機能の実装
Packageの中に置くModuleを決めた後，開発者はModuleの動作を示すINFファイルを作成しなければなりません。それは下記のものを含みます。
・Moduleタイプ
・必要なLibraryクラス
・必要なPPI，PROTOCOL，GUID，PCD
・他のModuleとの依存関係(Moduleタイプによりあったりなかったり）
ModuleのINFファイルを見ることで，あまり知らないModuleについて手軽に概要を知ることができます。
INFファイルを作成後，開発者は基本的な機能を実装すべくソースコードを書き始めましょう。
$WORKSPACE/MdePkg/Include/Libraryディレクトリ以下に，
サポート関数を提供する多くのライブラリがあります。また，種々のModuleタイプのための，エントリポイントのライブラリがあります。詳細はヘッダーファイルに書いてあるので是非参照してください。
Phase 3：ビルドのためのDSCファイルの作成
EDK IIでは，DSCファイルがPackageのビルド動作を記述します。それには下記が含まれます。
・ビルドに必要なModule
・種々のModuleタイプのためのLibraryインスタンスの選択
・Moduleによって使用されるPCDエントリの構成
単一PlatformのDSCや各々参照される別PackageのDECファイルが，Packageを定義します。
Package内のすべてのModuleをビルドするために，これらのファイルやModuleのINFファイルが必要です。
Phase 4：Moduleのチューニング
Moduleをチューニングするために下記のものを使用してください。
・コードをリユースするために，EDK II ライブラリ
・configurationのために，EDK II PCDメカニズム
EDK ModuleとEDK II Moduleの違いは，EDK II Moduleが必要であれば静的にも動的にもカスタマイズ可能であることです。
・Static Customizationは，ライブラリインスタンスを選んだり，ビルド時にPCDのFeatureFlagやFixed Typeを決めることが好まれます。
・Dynamic Customizationは，急いで動作をコントロールするためにパッチ可能/動的なPCDを使うことが好まれます。
EDK II Module開発者は，開発のできるだけ早い段階でどんなロジックがModuleの中に生成されるのか熟慮するべきです。例えば，もしなんらかの機能がcore Packageのライブラリクラス内ですでに実装された場合，開発者はその既存のライブラリクラスを使うべきです。
Build Infrastructure
EDK IIビルドシステムは，クロスプラットフォームでビルドできるようにするため，PythonとPortable Cコードに基づいています。
EDK II ビルドツールがメタデータ（DSC，DEC，INFファイル）を構文解析し，それに対応する一つのTop-level Makefile・Module毎のMakefile・Module毎のAutogen.c，Autogen.hが生成されます。
自動生成されるファイル内で，EDK IIビルドツールはModuleで使用される全てのGUIDs，Protocols，PPIs，PCDsを生成します。そして，Moduleのエントリポイント実装時に，使用されるライブラリインスタンスのすべてのconstructorsを呼びます。
