LSB 简介-白红宇

LSB 简介

阅读量：5843 次

发布时间：2019-06-18

本文共 6181 字，大约阅读时间需要 20 分钟。

前 Linux 的发行版非常繁多，为了促进 Linux 不同发行版间的兼容性，LSB（Linux Standards Base）开发了一系列标准，使各种软件可以很好地在兼容 LSB 标准的系统上运行，从而可以帮助软件供应商更好地在 Linux 系统上开发产品，或将已有的产品移植到 Linux 系统上。

在 IBM Bluemix 云平台上开发并部署您的下一个应用。

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 方面的标准化发展历程。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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）制定标准。给定企鹅的体形和三维标准之后，软件开发者就可以设计并裁减出各色花样的衣服（应用程序），这样不管穿在哪只企鹅身上，都会非常合身。

图1. LSB图标

在现有标准基础上，LSB 制定了应用程序与运行环境之间的二进制接口，这主要是基于以下标准：

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

实例：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 = 9PATCHLEVEL = 3

我们可以看出，在这两个发行版上，不但使用的文件不同，文件的内容和格式也完全不同。如果开发人员在自己的程序中使用这些信息，他们就很难使用一个统一的接口来获取发行版本的信息，因此必须为每种平台都定制一个脚本或开发一个程序才能实现这种功能，这无疑会增加很多工作量，而且所生成的程序的可移植性也会很差。

为了解决这个问题，LSB 规范中增加了对 lsb_release 接口及其输出格式的定义：lsb_release 的功能是打印与发行版本相关的信息，必须实现以下选项（详细规范的定义请参考http://refspecs.freestandards.org /LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html）：

表1. LSB对lsb_release 接口定义

我们前面已经介绍过，通过 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 -aLSB Version:   :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:logDistributor ID: RedHatEnterpriseESDescription:    Red Hat Enterprise Linux ES release 4 (Nahant Update 3)Release:        4Codename:       NahantUpdate3

在 SLES9SP3 上的结果如下：

# /usr/bin/lsb_release -aLSB 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-noarchDistributor ID: SUSE LINUXDescription:    SUSE LINUX Enterprise Server 9 (i586)Release:        9Codename:       n/a

我们可以看出，在这两个系统上，lsb_release 命令的位置、用法、输出格式都是相同的，因此开发人员可以使用它编写兼容性非常好的程序。

再看一下在这两个系统上与 lsb_release 有关的包，我们会发现二者之间有一些区别，例如在 SLES9SP3 上存在一个 /etc/lsb-release 文件，其中存放的是所遵循的 LSB 标准的版本，内容如下：

# cat /etc/lsb-releaseLSB_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 规范。