EFI Protocol VS C++
EFI Protocol VS C++1.Introduction
Protocol是EFI引出的新概念,翻翻EDK就会发现与protocol相关的code散落在EFI的各个角落,大到host bus driver,小到Hello Word App都和protocol 脱不了关系,因此毫不夸张的说protocol应该是EFI的精髓所在,DXE阶段模块之间的通信都经由protocol完成(我觉得PEI阶段的ppi应该和protocol一个概念,只不过是限于PEI的特殊性而稍有差异而已).EFI Driver基本上就是使用一堆protocol的实现的一个可执行的文件.一个protocol就是一堆函数指针和数据成员的集合,官方称呼为protocol interface structure;这个protocol必须要定义一个GUID作为它的唯一标识,DXE driver使用Boot Service table中的类似InstallProtocolInterface等函数将porotocol安装到device handle上这就叫做produce protocol, InstallProtocolInterface成功的话该protocol就是published,后续其它driver使用该protocol就只要用Boot Service table中的LocateProtocol等相关函数从handle database中索引出该protocol就可以了.protocol为DXE阶段模块之间的通信提供了非常有效的手段.
2.Protocol Implement OO
EFI是一个使用C实现的OO的Framework,它的OO特性主要经由protocl实现.EFI可以说是一个优秀的
Framework, 对它的扩展可以优雅的实现.使用过C++这类面向对象语言的朋友都会知道OO有三大基本特性:1.Encapsulation,2.Inheritance,3.Polymorphism. 那么既然EFI是使用protocol实现的OO,那么protocol是如何实现这三大特性的呢?
1.Encapsulation的实现其实比较简单,它所表达的信息隐藏的概念,这个部分在protocol中可以方便的实现,protocol通常是函数指针和属性的集合,我们导出函数的接口,而将数据属性放在函数接口内部处理.如下述EDK中的code所示:
typedef struct _EFI_CPU_ARCH_PROTOCOL {
EFI_CPU_FLUSH_DATA_CACHE
FlushDataCache;
EFI_CPU_ENABLE_INTERRUPT
EnableInterrupt;
EFI_CPU_DISABLE_INTERRUPT
DisableInterrupt;
EFI_CPU_GET_INTERRUPT_STATE
GetInterruptState;
EFI_CPU_INIT
Init;
EFI_CPU_REGISTER_INTERRUPT_HANDLER
RegisterInterruptHandler;
EFI_CPU_GET_TIMER_VALUE
GetTimerValue;
EFI_CPU_SET_MEMORY_ATTRIBUTES
SetMemoryAttributes;
UINT32
NumberOfTimers;
UINT32
DmaBufferAlignment;
} EFI_CPU_ARCH_PROTOCOL;
像NumberOfTimers, DmaBufferAlignment就是数据属性了.
2.Inheritance子类继承了父类的所有的方法和属性,在C的级别上表示就是内
存的叠加.同时它还代表的是IS-A的概念.如下面的sample所示B_PROTOCOL
继承自A_PROTOCOL.
typedef struct _ A_PROTOCOL {
UINT32
A;
}A_PROTOCOL;
typedef struct _ B_PROTOCOL {
A_ PROTOCOL
AP;
UINT32
B;
}B_PROTOCOL;
它们的类图如下图1所示,内存布局如下图2所示:
3. Polymorphism是面向对象的精髓所在了,如果没有了多态,则只能称之为基于对象了.多态是指基于相同的接口实现的不同的class(EFI之中应该是指实现protocol的driver),具有不同的行为.如两个EFI Driver A&B 它们都实现了ComponentName protocol,A在它的GetDriverName interface回复的Driver Name是”A”而Driver B则回复的是”B”,所以同样的接口具有不同的行为.protocol相当于一个共同的接口,因此我们可以以统一的方式去管理和配置这些实现了该protocol的这些Driver.如shell app dirver.efi它就是通过枚举Handle database找到挂在这些device handle上的ComponentName protocol,然后call它们的GetDriverName interface获悉driver的名字信息.
3.Who Win(Protocol vs C++)?
看上去貌似用protocol实现OO特性还是比较费事的,那么为什么不直接使用C++实现呢?我不知道真正
原因L!呵呵,可是我猜有可能的几种原因如下:
1. C++无法做到二进制级别上的复用,C++是一个非常复杂的语言,它有非常多的特性,C++标准委员会制定出了编译器厂商所需要实现的一堆特性,比如构造函数,析构函数,继承,重载,多态等等一堆的规则,但是标准委员会并没有规定编译器厂商如何实现这些特性于是问题就来了,我们使用A厂商编译器build driver da和B厂商编译器build同一只driver da它们的内存布局就不相同,于是二进制级别上的互操作就不可能了,设备厂商都要把source code拿出来放在一个编译器上build 才OK，不同的编译器实现不同的一个地方就体现在实现多态时，vptr存放的位置上，有一些编译器会把该指针放在对象内存布局的头部，有些厂商则喜欢放在尾部，这个差异非常大；如果存在多重继承那么就可能出现多个vptr那么vptr摆放的顺序又会有不同等等不胜其扰的问题。而protocol使用标准的c实现，它就没有二进制文件不一致的问题。
2．C++实现多态，虚继承以及name mangling等会带来空间以及编译时间上的开销。C++中的多态是通过在基类的函数声明中加上virtual实现的，这一个关键字里面大有文章，我们使用一个class VI演示该过程：
class VI
{
int a;
int b;
void test0(void) virtual;
};
没有virtual这个关键字的时候它的内存布局如下图3所示，加上之后就如图4所示：
编译器通过增加一个vptr虚函数指针，和vtbl虚函数表实现多态的功能，一旦子类改写了test0那么子类就会修改掉vtbl中的test0的地址。如此一来开销就来了J,一旦涉及到虚继承多重继承，那个开销就更大了。相比较来看protocol的实现就完全没有这个问题。
3．C++使用字符命名对象会有命名冲突的可能而protocol使用64位GUID是不可能出现命名冲突的。当project大到一定程度就会感受到变量命名冲突的讨厌了，你定义的变量可能在别的你不知道的模块里已经被用过了，然后编译器报上一大堆另人恐慌的错误出来。当然C++也有解决命名冲突的方法，那就是namespace可是这样又会造成性能上的影响。
所以综上所述，protocol应该较C++稍有优势一点哦J,它完整的实现了OO的所有特性，而无性能上的损耗只是感官上有些差异，如intel的spec所说的那样Look/fell very different.
That’s all!
Enjoy it!
Peter
[ 本帖最后由 peterhu 于 2009-7-13 17:05 编辑 ] 感觉从ASM转到C好难入手。 老外觉得EFI框架有这么那样的好处，但他们搞出来的这些，是人读的看的吗？好笑得很！
页:
[1]