EFI Load Image

      先描述下EFI Images的分类，总的来说，分为三类，分别如下：EFI AP、EFI Boot Service Drivers以及EFI Runtime Drivers。在接下来的篇幅中将一一介绍，首先对EFI Images进行总体介绍。
     EFI Images的装载和重载入内存都是通过导入服务gBS->LoadImages()来实现的。

对于EFI Images有很多存储位置来存放，主要有：
PCI card的可扩展ROMs ；
系统ROM和系统flash ；
媒体设备，例如：硬碟、软盘、CD或DVD ；
局域网导入服务 。
    
      
     EFI Images并不在一特定的地址下编译和连接，相反地，他们被编译和连接放置在EFI Images中，这就允许EFI Images被放置在系统MEMORY的任何一处。
  
     导入服务做如下工作：[gBS->LoadImages()]
     1，在载入Images时分配一定内存,allocates memory
     2, 自动应用再布置固定到 images.
     3, 在Handlebase 中创建新的 images Handle ，安装 EFI_LOADED_IMAGE_PROTOCOL。其中EFI_LOADED_IMAGE_PROTOCOL包含了EFI  
Images导入时信息。所有的 EFI 组件都能利用这些信息，因为这些信息是存放在 Handlebase 里的。
     在EFI Images通过gBS->LoadImages()之后，就可以通过调用gBS->StartImages()来执行开始。其中entry point 要接受2个参数：
1、The image handle of the EFI image being started
2、A pointer to the EFI System Table
     这2个项目允许 EFI images 做如下的工作：
一是：存取在平台上的可利用的所有的EFI Services；
二是：取回关于EFI从那里被装载和Images在内存中存放位置的一些信息。
     在EFI entry point的EFI Images运行操作变化依赖于EFI Images的类型。
下面就EFI Images的分类来说明，进行具体的描述：
(1) Applications
     EFI AP开始执行于entry point。执行至返回entry point或者调用Exit()导入函数。当它完成时，Images从内存中卸载，它不会长驻内存中。
一些EFI AP的普通例子，包括下面各项：
1，EFI Shell
2，EFI Shell commands
3，Flash utilities
4，Diagnostic utilities
从内部的其他EFI AP 调入EFI AP 是完全可接受的。

(2) OS loader
     EFI1.10里描述了一种特殊的EFI AP称之为OS boot loader。它是调用ExitBootServices（）的一个EFI AP。当OS loader已经建立好基下组织，准备好承担系统资源的所有权时将会调入ExitBootServices（），在执行ExitBootServices（）时，EFI Core将释放它的boot time services和drivers，仅留下runtime services和drivers。

(3) Drivers
     EFI drivers 与EFI AP不同，除非有一个错误返回到driver的entry point。drivers是常驻内存的。EFI core固件、boot 管理、其他EFI AP 可能载入drivers。
1°EFI 1.02 Drivers
     EFI 1.02 Drivers有很多类型，在EFI 1.02 中，没有通过定义Driver Model来构建drivers。EFI 1.10中提供Driver Model替代了EFI 1.02中建立的Drivers的方式，但仍然保持着向后兼容性（兼容于1.02 Drivers）。EFI 1.02 是直接在 entry point内开始driver的。这方法意味着那个driver将立即寻找支援的设置，安装必须的I/O protocols，并且启动需要获得计数设备的定时器。然而，这个方法并没有允许系统对driver导入及连接政策掌管控制。EFI 1.10中解决这些问题。
EFI 1.02 Drivers普通的例子：FPSWA Driver

2°Boot services和Runtime Services
    Boot time drivers载入内存后被记为EfiBootServicesCode，它们从内存分配他们的数据结构记之为EfiBootServicesData，通过调用gBS->ExitBootServices（）之后,这些内存类型将转化为可利用内存。
    Runtime drivers载入内存后被记为EfiRuntimeServicesCode，它们从内存分配他们的数据结构记之为EfiRuntimeServicesData，通过调用gBS->ExitBootServices（）之后,这些内存类型将被保存。
    当OS运作时，这保存的信息允许Runtime driver提供服务给OS。因为EFI handle database并不一直在OS运作时，所以Runtime driver一定要发表其他可能的召集机制。
典型的Runtime driver：FPSWA.efi/UNDI
    除了这些例子之外，runtime drivers不是很普遍，将不会被很详尽的讨论。加之，因为EFI支持的runtime services和runtime driver从物理寻址模式到虚拟寻址模式的转化，所以执行和确认runtime drivers比boot services drivers困难的多。