實現(xiàn)

相關模塊	相關指令
mod_so	LoadModule

Apache對獨立模塊的DSO支持是建立在只能被靜態(tài)編譯進Apache核心的mod_so基礎之上的，這是core以外唯一不能作為DSO存在的模塊，而其他所有已發(fā)布的Apache模塊，都可以通過安裝文檔中闡述中的編譯選項 --enable-module=shared 被獨立地編譯成DSO并使之生效。一個被編譯為mod_foo.so的DSO模塊，可以在httpd.conf中使用mod_so的LoadModule指令，在服務器啟動或重新啟動時被加載。

新提供的支持程序apxs(APache eXtenSion)可以在Apache源代碼樹之外編譯基于DSO的模塊，從而簡化了Apache DSO模塊的建立過程。其原理很簡單：安裝Apache時，configure的 make install 命令會安裝Apache C頭文件，并把依賴于特定平臺的編譯器和連接器參數(shù)傳給apxs程序，使用戶可以脫離Apache的發(fā)布源代碼樹編譯其模塊源代碼，而不改變支持DSO的編譯器和連接器的參數(shù)。

用法概要

Apache2.0 的DSO功能簡要說明：

1. 編譯并安裝已發(fā)布的Apache模塊，比如編譯mod_foo.c為mod_foo.so的DSO模塊：

   $ ./configure --prefix=/path/to/install --enable-foo=shared
$ make install

2. 編譯并安裝第三方模塊，比如編譯mod_foo.c為mod_foo.so的DSO模塊：

   $ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
$ make install

3. 配置Apache以便以后安裝共享模塊：

   $ ./configure --enable-so
$ make install

4. 用apxs在Apache源碼樹以外編譯并安裝第三方模塊，比如編譯mod_foo.c為mod_foo.so的DSO模塊：

   $ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.la

共享模塊編譯完畢后，必須在httpd.conf中用LoadModule指令使Apache啟用該模塊。

背景知識

現(xiàn)代的類Unix系統(tǒng)都有一種叫動態(tài)共享對象(DSO)的動態(tài)連接/加載的巧妙的機制，從而可以在運行時將編譯成特殊格式的代碼加載到一個可執(zhí)行程序的地址空間。

加載的方法通常有兩種：其一是在可執(zhí)行文件啟動時由系統(tǒng)程序ld.so自動加載；其二是在可執(zhí)行程序中手動地通過Unix加載器的系統(tǒng)接口執(zhí)行系統(tǒng)調用dlopen()/dlsym()進行加載。

按第一種方法，DSO通常被稱為共享庫(shared libraries)或者DSO庫(DSO libraries)，使用libfoo.so或libfoo.so.1.2的文件名，存儲在系統(tǒng)目錄中(通常是/usr/lib)，并在編譯安裝時使用連接器參數(shù) -lfoo 建立了指向可執(zhí)行程序的連接。通過設置連接器參數(shù) -R 或者環(huán)境變量LD_LIBRARY_PATH ，庫中硬編碼了可執(zhí)行文件的路徑，使Unix加載器能夠在可執(zhí)行程序啟動時定位到位于/usr/lib目錄中的libfoo.so ，以解析可執(zhí)行文件中尚未解析的位于DSO中的符號。

通常，DSO不會引用可執(zhí)行文件中的符號(因為它是通用代碼的可重用庫)，也不會有后繼的解析動作�？蓤�(zhí)行文件無須自己作任何動作以使用DSO中的符號，而完全由Unix加載器代辦(事實上，調用ld.so的代碼是被連入每個可執(zhí)行文件的非靜態(tài)運行時啟動代碼的一部分)。動態(tài)加載公共庫代碼的優(yōu)點是明顯的：只需要在系統(tǒng)庫libc.so中存儲一次庫代碼，從而為每個程序節(jié)省了磁盤存儲空間。

按第二種方法，DSO通常被稱為共享對象(shared objects)或DSO文件(DSO files)，可以使用任何文件名(但是規(guī)范的名稱是foo.so)，被存儲在程序特定的目錄中，也不會自動建立指向其所用的可執(zhí)行文件的連接，而由可執(zhí)行文件在運行時自己調用dlopen()來加載DSO到其地址空間，同時也不會進行為可執(zhí)行文件解析DSO中符號的操作。Unix加載器會根據(jù)可執(zhí)行程序的輸出符號表和已經加載的DSO庫自動解析DSO中尚未解析的符號(尤其是無所不在的libc.so中的符號)，如此DSO就獲得了可執(zhí)行程序的符號信息，就好象是被靜態(tài)連接一樣。

最后，為了利用DSO API的優(yōu)點，可執(zhí)行程序必須用dlsym()解析DSO中的符號，以備稍后在諸如指派表等等中使用。也就是說，可執(zhí)行程序必須自己解析其所需的符號。這種機制的優(yōu)點是允許不加載可選的程序部件，直到程序需要的時候才被動態(tài)地加載(也就不需要內存開銷)，以擴展程序的功能。

雖然這種DSO機制看似很直接，但至少有一個難點，就是在用DSO擴展程序功能(第二種方法)時為DSO對可執(zhí)行程序中符號的進行解析，這是因為，"反向解析"可執(zhí)行程序中的DSO符號在所有標準平臺上與庫的設計都是矛盾的(庫不會知道什么程序會使用它)。實際應用中，可執(zhí)行文件中的全局符號通常不是重輸出的，因此不能為DSO所用。所以在運行時用DSO來擴展程序功能，就必須找到強制連接器輸出所有全局符號的方法。

共享庫是一種典型的解決方法，因為它符合DSO機制，而且為操作系統(tǒng)所提供的幾乎所有類型的庫所使用。另一方面，使用共享對象并不是許多程序為擴展其功能所采用的方法。

截止到1998年，只有少數(shù)的軟件包使用DSO機制在運行時擴展其功能，諸如 Perl 5(通過其XS機制和DynaLoader模塊)，Netscape Server等。從1.3版本開始，Apache也加入此列，因為Apache已經用了基于指派表(dispatch-list-based)的方法來連接外部模塊到Apache的核心。所以Apache也就當然地在運行時用DSO來加載其模塊。

優(yōu)點和缺點

上述基于DSO的功能有如下優(yōu)點：

• 由于服務器包的裝配工作可以在運行時使用httpd.conf中的配置命令LoadModule來進行，而不是在編譯中使用編譯選項來進行，因此顯得更靈活。比如，只需要安裝一個Apache，就可以運行多個不同的服務器實例(如標準&SSL版本，濃縮&功能加強版本[mod_perl、PHP])。
• 服務器可以在安裝后使用第三方模塊被輕易地擴展。這至少對廠商發(fā)行包的維護者有巨大的好處，他可以建立一個Apache核心包，而為諸如PHP、mod_perl、mod_fastcgi等擴展另建附加的包。
• 更簡單的Apache模塊原型。使用DSO配合apxs，可以脫離Apache源代碼樹，僅需要一個 apxs -i 和一個 apachectl restart 命令，就可以把剛開發(fā)的新模塊納入到運行中的Apache服務器。

DSO有如下缺點：

• 由于并不是所有操作系統(tǒng)都支持動態(tài)加載代碼到一個程序的地址空間，因此DSO機制并不能用于所有平臺。
• 由于Unix加載器必須進行符號解析，服務器的啟動會慢20%左右。
• 在某些平臺上，位置獨立代碼(positon independent code[PIC])需要復雜的匯編語言技巧來實現(xiàn)相對尋址，而絕對尋址則不需要，因此服務器在運行時會慢5%左右。
• 由于DSO模塊不能在所有平臺上被其他基于DSO的庫所連接(ld -lfoo)，比如，基于a.out的平臺通常不提供此功能，而基于ELF的平臺則提供，因此DSO機制并不能被用于所有類型的模塊�；蛘呖梢赃@樣說，編譯為DSO文件的模塊只能使用由Apache核心、C庫(libc)和Apache核心所用的所有其他動態(tài)或靜態(tài)的庫、含有獨立位置代碼的靜態(tài)庫(libfoo.a)所提供的符號。而要使用其他代碼，就只能確保Apache核心本身包含對此代碼的引用，或者自己用dlopen()來加載此代碼。