LSB 簡介

目前 Linux 的發行版非常繁多，為了促進 Linux 不同發行版間的兼容性，LSB（Linux Standards Base）開發了一系列標準，使各種軟件可以很好地在兼容 LSB 標準的系統上運行，從而可以幫助軟件供應商更好地在 Linux 系統上開發產品，或將已有的產品移植到 Linux 系統上。

Unix/Linux 標準化歷史

標準化目前已經成為 Linux 系統上的一個熱門話題。實際上，在 Linux 誕生之初，這個問題就得到了重視。當 Linus 在開發 0.01 版本的 Linux 內核時，就開始關注 POSIX 標準的發展，他在 /include/unistd.h 文件中定義了幾個與 POSIX 有關的宏，以下內容就節選自 0.01 版本內核的 /include/unistd.h 文件：

/* ok, this may be a joke, but I'm working on it */
            #define _POSIX_VERSION 198808L
            

下面我們就從 POSIX入手開始介紹 Unix/Linux 方面的標準化發展歷程。

POSIX

Unix 1969 年誕生于 AT&T 貝爾實驗室，并在 1973 年使用 C 語言進行了重寫，從此就具有了很好的可移植性。但是當 AT&T 在 1984 年由于分拆而得以進入計算機領域的市場之后，卻引發了 Unix 業界的一場大戰。當時最為主要的兩個版本是 AT&T 的 System V 和伯克利的 BSD。二者在技術方面（例如終端）和文化方面都存在很多分歧，導致應用程序很難在不同的系統上平滑地進行移植，為了解決這個問題，IEEE（Institute of Electrical and Electronic Engineers）的 1003 委員會著手開發了一系列標準，這就是后來的 POSIX（Portable Operating System Interface for UNIX）標準。其目的是為那些兼容各種 UNIX 變種的應用程序制定應用程序編程接口（API）規范，從而確保這些應用程序的兼容性。這些標準后來被 ISO/IEC 采納，成為 ISO/IEC 9945 標準。

POSIX 在 15 份不同的文檔中對操作系統與用戶軟件的接口進行了規范，主要內容包括3個部分：

• POSIX 系統調用
• POSIX 命令和工具
• POSIX 兼容測試

同時還提供了一套 POSIX 兼容性測試工具，稱為 PCTS（POSIX Conformance Test Suite）。

后來 POSIX 標準又進行了很多擴充，主要包括：

• POSIX.1，核心服務：主要集成了 ANSI C 標準，包括進程創建和控制、信號、浮點異常、段錯誤、非法指令、總線錯誤、定時器、文件和目錄操作、管道、C 標準庫、I/O 端口和控制
• POSIX.1b，實時擴展：包括優先級調度、實時信號、時鐘和定時器、信號量、消息傳遞、共享內存、異步和同步 I/O、內存鎖
• POSIX.1c，線程擴展：包括線程創建和控制、線程調度、線程同步、信號處理

POSIX 最初的設計目標是為 Unix System V 和 BSD Unix 等 Unix 系統上的特性制定規范，使其可以實現更好的可移植性。但是很多其他系統都也兼容POSIX 標準。例如，微軟的 Windows NT 就兼容 POSIX 標準的實時部分（POSIX.1b），而 RTOS（LynxOS real-time operating system）也與 POSIX 標準兼容。Windows 上可以通過安裝 Windows 的 Services for UNIX 或 Cygwin 來增強對 POSIX 標準的兼容度。

Open Group

Open Group 是現在 Unix 商標的擁有者，其前身是 X/Open。X/Open 是 Unix 廠商在 1984 年成立的一個聯盟，它試圖為眾多 Unix 變種定義一個安全公共子集，因此即使在 Unix 混戰的年代，也得到了比較好的發展。在 1993 年，包括主要 Unix 公司在內的75 家系統和軟件供應商委托 X/Open 為 Unix 制定一個統一的規范。X/Open在現有標準基礎上，增加了對終端進行處理的 API 和 X11 API，并全面兼容 1989 ANSI C 標準，最終誕生了第一版本的單一 Unix規范（Single Unix Specification，簡稱 SUS）。

X/Open在 1996 年與 OSF（開放軟件基金會）進行合并，成立了 Open Group 組織，專門從事開放標準的制定和推廣工作，并對很多領域提供了認證，包括 Unix 操作系統、Motif 和 CDE（Common Desktop Environment）用戶界面。

Austin Group

Austin Group 是在 1998 年成立的一個合作技術工作組，其使命是開發并維護 POSIX.1 和 SUS 規范。Austin Group 開發規范的方法是"write once, adopt everywhere"，即由 Austin Group 制定的規范既會成為 IEEE POSIX 規范，又會成為 Open Group 的 技術標準規范，以后又會被采納為 ISO/IEC 的標準。新開發的規范后來就被標準化為 ISO/IEC 9945 和IEEE Std 1003.1，并成為 SUSV3 的核心部分。

這種獨特的開發模式最大限度地利用了業界領先的工作成果，將正式的標準化工作轉化成了一個唯一的行為，并且吸引了廣泛的參與者。Austin Group 目前有 500 多個參與者，工作組的主席是 Open Group 的 Andrew Josey。

LSB

在90 年代中期，Linux 也開始了自己的標準化努力。實際上，Linux 一直都試圖遵守 POSIX 標準，因此在源代碼級上具有很好的兼容性，然而對于 Linux 來說，僅僅保證源碼級的兼容性還不能完全滿足要求：在 Unix 時代，大部分系統都使用的是專有的硬件，軟件開發商必須負責將自己的應用程序從一個平臺移植到其他平臺上；每個系統的生命周期也很長，軟件開發商可以投入足夠的資源為各個平臺發布二進制文件。然而 Linux 使用的最廣泛的 x86 通用平臺，其發行版是如此眾多，而發展卻如此之快，軟件開發商不可能為每個發行版都發布一個二進制文件，因此就為 Linux 上的標準化提出了一個新的要求：二進制兼容性，即二進制程序不需要重新編譯，就可以在其他發行版上運行。

實際上，在 Linux 社區中第一個標準化努力是文件系統層次標準（Filesystem Hierarchy Standard，FHS），用來規范系統文件、工具和程序的存放位置和系統中的目錄層次結構，例如 ifconfig 命令應該放在 /usr/bin 還是 /usr/sbin 目錄中，光驅應該掛載到 /mnt/cdrom 中還是 /media/cdrom 中。這些需求最終共同促進了 Linux Standard Base（LSB）項目的誕生。

LSB目前是 FSG（Free Standards Group）中最為活躍的一個工作組，其使命是開發一系列標準來增強 Linux 發行版的兼容性，使各種軟件可以很好地在兼容 LSB 標準的系統上運行，從而可以幫助軟件供應商更好地在 Linux 系統上開發產品，或將已有的產品移植到 Linux 系統上。

LSB 以 POSIX 和 SUS 標準為基礎，并對其他領域（例如圖形）中源代碼的一些標準進行了擴充，還增加了對二進制可執行文件格式規范的定義，從而試圖確保 Linux 上應用程序源碼和二進制文件的兼容性。

回頁首

LSB 簡介

LSB 是 Linux 標準化領域中事實上的標準，它的圖標（請參看圖 1）非常形象地闡述了自己的使命：對代表自由的企鵝（Linux）制定標準。給定企鵝的體形和三維標準之后，軟件開發者就可以設計并裁減出各色花樣的衣服（應用程序），這樣不管穿在哪只企鵝身上，都會非常合身。

在現有標準基礎上，LSB 制定了應用程序與運行環境之間的二進制接口，這主要是基于以下標準：

• Single UNIX Specification（SUS）
• System V Interface Definition（SVID）
• compilers for the Intel Itanium processor
• C++ ABI
• System V Application Binary Interface（ABI）

同時，LSB 充分吸取了 UNIX 標準化努力所取得經驗和教訓，回避了這些標準的一些問題。例如，POSIX 僅僅定義了編程接口的標準，但是它卻無法保證二進制的兼容性。而諸如 OSF/1 之類的標準雖然試圖解決二進制兼容性的問題，但是限制卻太為嚴格。LSB 在二者之間達成了一個平衡，它包含了一個二進制兼容層，同時消除了 POSIX 與 OSF/1 之間存在分歧的地方。

LSB 對各個庫提供的接口以及與每個接口相關的數據結構和常量進行了定義，圖2給出了 LSB 3.1 環境中所包含的組件。這些組件包括開發者所需要的共享庫（包括 C++），文件系統層次結構（FHS）、對象文件格式、命令和工具、應用程序包、用戶和組、系統初始化等所采用的規范：

組織架構

為了保證 LSB 項目的良好運行，LSB 采用了自己的完整組織架構來負責整個項目的運行，包括主席、選舉委員會、執行委員會：

• 主席：由選舉委員會選舉產生，任期兩年，負責 LSB 項目的整體運作，并對 FSG 和社區代表 LSB項目。目前的主席是 Debian 的創始人 Ian Murdock.。
• 選舉委員會：由所有對 LSB 作出貢獻的人組成，負責在主席任期期滿時選舉下一任主席。
• 執行委員會：由主席和各個子項目的領導人以及對 LSB
• 項目有重大貢獻的人組成，可以對外作為 LSB 項目的發言人。

工作組

LSB 項目包含幾個子項目（也稱為工作組），分別負責不同的職責范圍，簡介如下：

• Specification SubGroup：負責開 LSB 規范的開發與維護，還要負責 ISO/IEC 23360（即 ISO LSB 標準的維護）。具體職責如下：
  • 維護 LSB 規范數據庫
  • 編寫 LSB 規范
  • 開發并維護生成規范文檔所需要的工具
• LSB Tools SubGroup：負責以下子項目的開發和實現：
  • SI（Sample Implementation）：遵守 LSB 規范的一個參考實現
  • Development Environment：開發符合 LSB 規范的應用程序的開發環境
  • Application Battery：符合 LSB 規范的樣例應用程序，例如 lsb-apache
• LSB Test SubGroup：負責按照 LSB 規范的定義，開發一些測試套件，來驗證用戶環境和應用程序是否符合 LSB 規范，主要包括：
  • LSB Runtime Tests：包括ANSI、POSIX、LSB-OS、線程、用戶和組、FHS、國際化、PAM（可插入認證模塊）等測試套件
  • LSB VSW4/XTS5 Test：Xlib11及其擴展庫的測試套件
  • LSB C++ Test：C++ 測試套件
• LSB Desktop SubGroup：負責開發與桌面有關的規范的測試套件，用來驗證用戶環境和應用程序是否符合 LSB 規范，主要包括：
  • GTK 庫
  • OpenGL 庫
  • PNG12庫
  • JPEG 庫
  • Fontconfig 庫
  • GTK+ Stack 庫
  • QT3/4 庫
  • XML2 庫
• LSB Future SubGroup：負載開拓 LSB 的新領域，將已經發展比較成熟可以進行標準化但 LSB 尚未涉及的領域納入 LSB 標準范圍內

LSB 的標準化流程

LSB 對于標準的制定和推廣遵循務實的原則，它自己不會自行制定標準然后強行要求業界接受，而是把業界中已經成熟的技術和規范采用標準化的形式固定下來，然后大力加以推廣，這樣可以更廣泛地為軟件供應商和用戶接受。

一個新領域要想納入 LSB 標準的范疇，必須經過以下 3 個步驟：

2. 調研：調查上游軟件維護者是否還在積極維護，軟件是否穩定，是否具有很好的向后兼容性。

3. 實現：將該領域加入 LSB 數據庫、編寫規范、編寫測試套件、并將其加入開發環境、SI 和 APPBAT。

經過這 3 個步驟之后，LSB Future SubGroup 就會將其提交給 LSB 工作組，將其包含到 LSB 的下一個版本中進行發布，并對外提供認證服務。

認證

在制定好標準并開發出測試套件之后，為了區分系統或應用程序是否兼容 LSB 標準， FSG 提供了 LSB 標準認證服務。任何 Linux 發行版廠商和應用程序開發商都可以進行 Linux 認證，目前提供的認證有兩種：

• LSB 運行環境：為平臺供應商提供的 LSB 標準認證
• LSB 應用程序：為應用程序開發商提供的 LSB 標準認證

對于平臺供應商來說，經過 LSB 認證之后，就可以確保自己的系統所提供的服務都是標準的，任何遵守 LSB 標準的應用程序都可以很好地在自己的系統上運行；而對于應用程序開發商來說，其意義則剛好相反：不需要擔心自己的應用程序在遵守 LSB 標準的系統上的可移植性問題。

LSB 認證過程包含以下步驟：

• 注冊：要進行 LSB 認證的第一個步驟是在 https://www.freestandards.org/index.php?title=Special:Userlogin 上先創建一個帳號，并注冊您的公司和產品。
• 測試和驗證：使用 LSB 提供的測試工具，在您的測試系統上運行，并對結果進行分析（詳細內容請參看本系列的下一篇文章），確保您的系統或應用程序遵守 LSB 規范。
• 最終審計：在準備好正式提交測試結果之后，需要先簽署 LSB 認證協議和 LSB 商標許可協議，并向 FSG 支付認證所需要的費用。然后 FSG 會有專人對測試結果進行審計，如果一切正常，就通過了 LSB 認證。通過 LSB 認證的產品都會在 http://www.freestandards.org/en/Products 公開發布。目前已經 Redhat、Suse、RedFlag 等公司都已經通過了 LSB 3.0 的認證，對于 LSB 3.1 的認證正在進展中。

通過 LSB 認證之后，所認證的產品可以貼上 "LSB Certified" 的標簽進行銷售了。

認證問題報告

在運行 LSB 所提供的測試工具時可能會出現部分測試用例失敗的情況，其原因可能是產品本身的問題，例如 FHS 標準要求系統中必須存在 /media/ 目錄，而在某些系統中，這個目錄可能并不存在，此時就可能會導致相應的測試套件失敗，錯誤信息如下：

10|715 /tset/LSB.fhs/root/media/media-tc 00:55:04|TC Start, scenario ref 720-0
            15|715 3.7 5|TCM Start
            400|715 1 1 00:55:04|IC Start
            200|715 1 00:55:04|TP Start
            520|715 1 30056 1 1|Reference 3.11-1(A)
            520|715 1 30056 1 2|The /media directory exists and is searchable
            520|715 1 30056 1 3|/media: directory not found
            520|715 1 30056 1 4|exit code 1 returned, expected 0
            220|715 1 1 00:55:04|FAIL
            

但是有時可能并非是測試環境的問題，而是測試套件本身的問題，或者是由于系統中存在一個公認但卻暫時無法修復的問題，此時并不影響 LSB 的認證的結果。如果出現這種問題，測試人員可以將這個問題反饋給 LSB（http://www.freestandards.org/cert/prsubmit.php），經過確認之后，LSB 會在一個 waiver 文件中列出這種情況，并將對應的測試套件暫時剔除，并嘗試在下一個版本中進行修復。我們也可以從 http://www.freestandards.org/cert/pr.php 上查看已經發現的問題。

回頁首

LSB 的歷史、現狀和將來

LSB 項目最初發起于 1998 年 5 月，其項目啟動宣言得到了 Linus Torvalds、Bruce Perens、Eric Raymond 等人的簽名支持，當時的目標是建立一系列構建 Linux 發行版所采用的源代碼應該遵循的標準，并提供一個參考平臺。2000 年 5 月，LSB 成為 Free Standards Group（FSG） 的一個工作組。FSG 是一個獨立的非盈利組織，專注于通過開發和促進標準來加速開源軟件的發展。

從 2001 年 6 月發布第一個正式版本的規范以后，LSB 規范幾乎每 6 個月都會進行一次更新。截止到 2005 年 7 月發布的 3.0 版本為止，LSB 重點關注的是服務器端的使用，這與 Linux 在服務器端得到了廣泛的應用是一致的。這個規范已經被 ISO 采納為國際標準 23360。

目前最新的版本規范是 2005 年 10 月發布的 LSB 3.1，目前它可以支持 7 種體系結構：

• IA32
• IA64
• X86_64
• PPC32
• PPC64
• S390
• S390x

由于平臺的差異，所有的規范除了有一個通用的版本之外，還都存在一個適用于特定平臺的版本，其中的內容是完全適用于這個平臺的。

與上一個版本相比，LSB 3.1 版本的規范主要是增強了對桌面系統的標準化支持，增加了對 GTK 和 QT GUI 工具包的標準化。另外，LSB 還調整了自己的路線圖，以便可以與主流的 Linux 發行商（Redhat、Novell、Asianux、Debian 等）的發行計劃更好地吻合，并吸引了更多 Linux 發行商的參與，對開發工具和文檔進行了改進，還與各個國家的組織（例如中國電子技術標準化研究所，CESI）進行認證方面的合作。

下一個版本 LSB 3.2 將在 2007 年第二季度發布，將主要增加 freedesktop.org 的標準和跨桌面的交互操作性。

LSB 4.0 將在 2008 年發布，它將實現更好的二進制兼容性，并增加對 Perl、Python、LAMP、Java 等語言的標準化支持。詳細路線圖及各個主要版本的特性如圖 3 所示：

回頁首

實例：lsb_release 的規范定義和實現

我們知道，在 /etc 目錄中有一個文件可以查看當前系統的版本信息，在 RHEL4U3（Red Hat Enterprise Linux 4 Update 3）上這個文件是 /etc/redhat-release：

# cat /etc/redhat-release
            Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
            

在 SLES9SP3（SUSE LINUX Enterprise Server 9 Service Pack 3）上這個文件是 /etc/SuSE-release：

# cat /etc/SuSE-release
            SUSE LINUX Enterprise Server 9 (i586)
            VERSION = 9
            PATCHLEVEL = 3
            

我們可以看出，在這兩個發行版上，不但使用的文件不同，文件的內容和格式也完全不同。如果開發人員在自己的程序中使用這些信息，他們就很難使用一個統一的接口來獲取發行版本的信息，因此必須為每種平臺都定制一個腳本或開發一個程序才能實現這種功能，這無疑會增加很多工作量，而且所生成的程序的可移植性也會很差。

為了解決這個問題，LSB 規范中增加了對 lsb_release 接口及其輸出格式的定義：lsb_release 的功能是打印與發行版本相關的信息，必須實現以下選項（詳細規范的定義請參考http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html）：

我們前面已經介紹過，通過 LSB 認證發行版或軟件可以得到 FSG/LSB 的授權，貼上 "LSB Certified"的標簽進行銷售。實際上，在通過 LSB 認證的系統上，我們可以看到一個與 LSB 有關的包，其中包含了 LSB 規范中對 lsb_release 接口規范的實現。lsb_release 是 LSB-Core-generic 規范中要求的一個接口，各種平臺（目前可以支持的 7 種平臺： IA32、IA64、X86_64、PPC32、PPC64、S390 和 S390x）上都應該提供這個接口的實現。在 RHEL4U3 上，我們可以找到一個名為 redhat-lsb 的包（RHEL4U3 遵守的是 LSB 3.0 版本的規范，因此這個包的版本是 redhat-lsb-3.0-8.EL），該包的內容如下：

# rpm -ql redhat-lsb
            /bin/mailx
            /etc/lsb-release.d
            /etc/lsb-release.d/core-3.0-ia32
            /etc/lsb-release.d/core-3.0-noarch
            /etc/lsb-release.d/graphics-3.0-ia32
            /etc/lsb-release.d/graphics-3.0-noarch
            /etc/redhat-lsb
            /etc/redhat-lsb/lsb_killproc
            /etc/redhat-lsb/lsb_log_message
            /etc/redhat-lsb/lsb_pidofproc
            /etc/redhat-lsb/lsb_start_daemon
            /lib/ld-lsb.so.3
            /lib/lsb
            /lib/lsb/init-functions
            /usr/bin/lsb_release
            /usr/lib/lsb
            /usr/lib/lsb/install_initd
            /usr/lib/lsb/remove_initd
            /usr/sbin/redhat_lsb_trigger.i386
            /usr/share/man/man1/lsb_release.1.gz
            

而在 SLES9SP3 中，這個包的名字是 lsb（lsb-3.0-4.8），它包含的內容如下：

# rpm -ql lsb
            /etc/lsb-release
            /etc/lsb-release.d
            /etc/lsb-release.d/graphics-2.0-ia32
            /etc/lsb-release.d/graphics-2.0-noarch
            /etc/lsb-release.d/graphics-3.0-ia32
            /etc/lsb-release.d/graphics-3.0-noarch
            /lib/ld-lsb.so.2
            /lib/ld-lsb.so.3
            /usr/bin/lsb_release
            /usr/share/man/man1/lsb_release.1.gz
            

我們可以看出，在這兩個發行版上的兩個包中存在一些共同的文件：

• /usr/bin/lsb_release
• /lib/ld-lsb.so.3

其中 /lib/ld-lsb.so.3 在兩個系統上都是一個符號鏈接：

# ls -l /lib/ld-lsb.so.3
            lrwxrwxrwx  1 root root 13 Apr 20 03:04 /lib/ld-lsb.so.3 -> ld-linux.so.2
            

系統中提供的大部分應用程序都是鏈接到了 ld-linux.so.2 上，但是兼容 LSB 標準的應用程序都可以鏈接到 ld-lsb.so.3 上（由于 SLES9SP3 還兼容 LSB 2.0 的規范，因此系統中還存在一個 /lib/ld-lsb.so.2 庫，也是指向 ld-linux.so.2 的符號鏈接；而 RHEL4U3 不兼容 LSB 2.0 的規范，因此沒有這個庫）。

而 /usr/bin/lsb_release 就是對 lsb_release 接口的具體實現，在這兩個系統上都是一個 shell 腳本。下面我們分別在這兩個系統上執行 lsb_release -a 命令，在 RHEL4U3 上的結果如下：

# /usr/bin/lsb_release -a
            LSB Version:
            :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:log
            Distributor ID: RedHatEnterpriseES
            Description:    Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
            Release:        4
            Codename:       NahantUpdate3
            

在 SLES9SP3 上的結果如下：

# /usr/bin/lsb_release -a
            LSB Version:
            core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32:graphics-2.0-ia32:
            graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch
            Distributor ID: SUSE LINUX
            Description:    SUSE LINUX Enterprise Server 9 (i586)
            Release:        9
            Codename:       n/a
            

我們可以看出，在這兩個系統上，lsb_release 命令的位置、用法、輸出格式都是相同的，因此開發人員可以使用它編寫兼容性非常好的程序。

再看一下在這兩個系統上與 lsb_release 有關的包，我們會發現二者之間有一些區別，例如在 SLES9SP3 上存在一個 /etc/lsb-release 文件，其中存放的是所遵循的 LSB 標準的版本，內容如下：

# cat /etc/lsb-release
            LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32"
            

而在 RHEL4U3 上并沒有這個文件，但是在 /etc/lsb-release.d 目錄中的文件卻比 SLES9SP3 上多：

• /etc/lsb-release.d/core-3.0-ia32
• /etc/lsb-release.d/core-3.0-noarch
• /etc/lsb-release.d/graphics-3.0-ia32
• /etc/lsb-release.d/graphics-3.0-noarch

而在 SLES9SP3 上只有以 graphics 開頭的文件。仔細查看一下 /usr/bin/lsb_release的實現我們就會發現，所遵守的 LSB 規范的列表既可以保存在 /etc/lsb-release 文件中，也可以以文件的形式放到 /etc/lsb-release.d 目錄中。因此 LSB 只是對接口定義進行了規范，但卻沒有限定具體的實現，這樣既可以為發行版供應商提供充分的自由，又為應用程序開發人員提供了一致的接口，可以得到最大限度的推廣和應用。

回頁首

結束語

標準化的 Linux 操作系統可以為應用程序開發者提供一個開發應用程序的良好平臺，使他們開發的應用程序可以非常平滑地移植到其他發行版本上。LSB 通過定義一系列規范，并提供標準測試套件和開發環境，可以幫助開發人員更容易地開發遵守規范的應用程序，輔助供應商構建更標準的系統。在本系列的下一篇文章中，我們將介紹如何使用 LSB 標準提供的測試工具來驗證系統和應用程序是否遵守 LSB 規范。