|
CONTAINING_RECORD IN EFI
, I; ~3 i% u) R; Z8 |
2 f0 }7 U$ D* L. ?& UEFI BIOS几乎全部用C完成,它几乎将C语言的各种技巧发挥到了极致。C的精髓泰半是指针,另外宏也是非常值得称道的。程序员对于宏的评价可谓褒贬不一,有人说它是万恶之源,有人则赞其为一把利刃。我个人觉得运用之妙,存乎一心,宏不是万能的,但是有一些场合使用宏确实可以大大的提高程序的可读性,有些跨平台的特性离开了宏还真是不行。_CR是EFI之中经常会被用的宏,我们来看看它的庐山真面目吧:
! w( d7 U+ d3 P: E% N$ t+ X( h8 P( S
//
+ a& N3 @3 P' R2 Q/ b5 |+ p//
' V- E' I, U$ fCONTAINING_RECORD - returns a pointer to the structure
# G1 s1 F+ M$ ]- q//
% V! @/ k6 O7 s% }from one of it's elements. 1 q8 V1 i8 m( j
// 7 o/ M2 t% u% j. V6 C
#define _CR(Record, TYPE, Field)6 N) ^% ^) d* L6 M% O
((TYPE *) ((CHAR8 *) (Record) - (CHAR8 *) &(((TYPE *) 0)->Field)))+ R }- j* b# W( J0 R" I
这个宏的作用是根据一个结构体成员变量的的地址获得该结构体基地址。举例如下:, y6 ~: K& l7 d$ V. ^+ O1 u1 \
struct _Test- k" O# C. u' @* \' w5 H
{' r+ Y/ Z! ^, o( y9 B Z0 Y: s( Q
CHAR8 t0;! |8 j2 }0 [% y( M
0 x' F* B4 j# [
UINT16 t1;
6 ?$ D% [, d4 A) `- p) e& X. }
) F0 h5 I t- i3 aUINT8 t2;& ]/ G1 Z. O8 N: T4 x$ ]- `
3 b# K0 v, |* [- a( s
UINT32 t3;3 e' e) l8 @7 s1 A$ q
};
( l! e$ _ N2 I% S4 m# z8 U% \5 F3 N* Q0 s$ k6 y
我们在某一个地方获得了t2的地址t2Ptr,这时如果要得到t2所在结构体的基地址就可以这样做:struct _Test* bPtr = _CR(t2Ptr,struct _Test,t2);预处理展开之后就是这副样子 struct _Test* bPtr = ((struct _Test*)((CHAR8*)(t2Ptr)-(CHAR8*)&((struct _Test *)0)->t2),其实我觉得关键的部分在这句“(TYPE *) 0)->Field”,它其实就是获得该成员在结构体中的偏移位置(offset),该成员变量的地址减去它在结构体中的偏移也就获得了基地址了。
) v9 v$ t* w+ Z) }9 ]# x/ E& P+ m
# |4 F2 ]5 N0 n1 F [
一图胜千言,如上图所示,假设t2的地址是0x1005,那么bPtr应该是多少呢?我们只要用t2-t2的offset(0x03)即可,也就是0x1002。是不是很简单?
5 [/ F6 h o! _% c# \3 _1 x& c% ^8 Y, ?$ h
大概是英雄所见略同吧,这种形式的宏在Linux kernel 和 Windows Kernel中也都有存在,只不过名字叫的不一样罢了。先看看Linux下长的什么样子吧:$ F5 H8 k3 g. J1 D/ _0 R) q8 n
/** 0 |5 a* B; R+ c
) u7 H1 ~/ G( D" b$ O0 k
* container_of - cast a member of a structure out to the containing structure
9 R$ w4 e0 c( w. x" E3 ]' n
5 o. u+ q' d/ d/ r*
8 C: [$ q" X2 S1 `# k. l9 n9 O
3 L2 l* u, h5 D0 n* @ptr:
6 l0 Y* l, r* L5 V) E# Z$ Cthe pointer to the member. . E: p6 V# i. h$ W. Q* u
( b" d: |/ y3 ?6 o6 C* @type:( k3 D3 I. \9 d# G1 `
the type of the container struct this is embedded in.
5 \* ?8 l# J$ n$ w$ F1 w
( A3 c* }# v1 \% j5 L3 e* @member:
8 O- F$ [( C9 x M9 ~' A3 @+ ithe name of the member within the struct.
! W' Z7 q+ O# z/ O8 ^4 @: ~* g7 G0 d4 [ I/ i( p) Q' w9 d
* 1 w6 m. i) m2 W0 z* {, J& e
& ]4 w0 s6 f. J% \$ P$ h- T
*/
- `9 F6 Y3 f, e" q#define
0 i& `. A8 m; p- h) J# ]container_of(ptr, type, member) ({! G: H& M# M: {7 R
\
) {: q/ T% [! r' R7 I6 L, _0 d; W9 I% D; H
const typeof( ((type *)0)->member ) *__mptr = (ptr);; ?, |4 N5 J- r
\) i8 ~# D$ m. w9 d
6 b8 @( ?7 Y$ _0 A( d(type *)( (char *)__mptr - offsetof(type,member) );})
: k& H3 z D' E; K% H. w6 W. v. b( `" }; b3 V' p' q+ j4 T
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
0 [+ C. Q( a6 F5 T' Q' @' h) H, ?, S" l" R8 | O
再来看看它在Windows Kernel中的小模样J:
- r' y% ^$ N% p#define% f& c+ |1 g P! Z1 Z& {# A+ T
CONTAININT_RECORD(address, type, field) \
3 g4 J* J2 \2 _) K ((type*)((PCHAR)(address) - (PCHAR)(&((type*)0)->field)))/ W: G5 L9 J' ]% n( P4 K" ]
他们的作用都是一样的,是不是有点天下文章一大抄的感觉啊,呵呵…
5 c& N* l" V% E, o5 O, \ U9 Q# G. k& Y: j
5 B& M' N, ?, S& ~: } I
/ o5 g) L- H! N8 r$ w1 D3 r1 fPeter& d( K3 T- d" O" _) c, z
, b. v& ~' p6 {2009-10-6 |