[Reprint] LSB

Original link: http://www.cnblogs.com/jinanxiaolaohu/p/11063419.html

LSB Profile

Feng Rui
, 2006 August 7 released

 

HTTPS: // www.ibm.com/developerworks/cn/linux/l-lsb-intr/ 

learn about before I do not know what it means LSB_RELEASE 

originally Standard Linux Base mean.

 

 

 

 

Unix / Linux standardization history

Standardization has become a hot topic on the Linux system. In fact, at the beginning of the birth of Linux, this problem has been seriously. When Linus in the development of version 0.01 of the Linux kernel, it began to focus on the development of the POSIX standard, he and POSIX defines several related macros in /include/unistd.h file, on the following excerpt from the 0.01 version of the kernel / include /unistd.h file:

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

Here we start from the POSIX began to introduce standardized development Unix / Linux area.

POSIX

Unix 1969 was born in the AT & T Bell Laboratories, and use the C language was rewritten in 1973, since then it has a very good portability. But when AT & T spin-off in 1984 due to enter the market while the computer field, has led to a war Unix industry. At that time most of the two versions is the main AT & T's System V and Berkeley BSD. Both in terms of technology (such as a terminal) and there are a lot of cultural differences cause the application difficult to transplant smoothly on different systems, in order to solve this problem, IEEE (Institute of Electrical and Electronic Engineers) 1003 Commission to proceed We developed a series of standards, which is later POSIX (Portable Operating System Interface for UNIX) standard. The aim is to develop an application programming interface (API) specifications as those compatible with all variants of UNIX applications to ensure the compatibility of these applications. These standards came to be ISO / IEC adopted as ISO / IEC 9945 standard.

POSIX 15 different parts of the document with a user interface to the operating system software of the specification, including three main parts:

• POSIX system calls
• POSIX commands and tools
• POSIX compatibility test

It also provides a set of POSIX compatibility testing tool called PCTS (POSIX Conformance Test Suite).

Later POSIX standard has been a lot of expansion, including:

• POSIX.1, Core Services: Major integrated ANSI C standard, including process creation and control signals, floating point exceptions, mistakes, illegal instructions, bus errors, timers, file and directory operations, pipes, C standard library, I / O ports and control
• The POSIX.1b, real-time extension: a priority scheduling, real-time signal, a clock and a timer, semaphores, messaging, shared memory, synchronous and asynchronous I / O, memory lock
• POSIX.1c, expansion thread: thread creation and control including, thread scheduling, thread synchronization, signal processing

POSIX original design goal is to develop specifications for the properties on the Unix System V and BSD Unix and other Unix systems, making it possible to achieve better portability. But many other systems are also compatible with the POSIX standard. For example, Microsoft's Windows NT-compatible real-time on the part of the POSIX standard (POSIX.1b), and RTOS (LynxOS real-time operating system) is also compatible with the POSIX standard. Windows can enhance the degree of compatibility of the POSIX standard by installing the Windows Services for UNIX or Cygwin.

Open Group

Open Group is now the owner of the Unix trademark, the predecessor of X / Open. X / Open is a Unix vendor alliance established in 1984, it attempted to define a common subset of security for many Unix variants, even in the era of Unix melee, has been relatively good development. In 1993, including major companies, including 75 Unix systems and software vendors entrust X / Open specification to develop a unified Unix. X / Open existing standard based on the increase of API and X11 API terminal for processing, and is fully compatible with 1989 ANSI C standard, eventually gave birth to the first version of the Single Unix Specification (Single Unix Specification, referred to as SUS).

X / Open in 1996 and the OSF (Open Software Foundation) merged to form The Open Group, specializes in the development and promotion of open standards work, and provides certification in many areas, including the Unix operating system, Motif and CDE ( Common Desktop Environment) user interface.

Austin Group

Austin Group is a joint technical working group was established in 1998, its mission is to develop and maintain POSIX.1 and SUS specification. Austin Group to develop standardized methods is "write once, adopt everywhere", that is developed by the Austin Group will not only become the norm IEEE POSIX specification, will become the Open Group's technical standards, the future will be adopted as ISO / IEC standard . The new specification was developed later standardized as ISO / IEC 9945 and IEEE Std 1003.1, and a core part of SUSV3.

This unique development model to maximize the use of industry-leading results of the work, the formal standardization transformed into a unique behavior and attract a wide range of participants. Austin Group currently has more than 500 participants, the Chairman of the Working Group is the Open Group Andrew Josey.

LSB

In the mid-1990s, Linux also started his own standardization efforts. In fact, Linux has been trying to comply with the POSIX standard, and therefore has good compatibility at the source code level, but for Linux, the only guarantee of source-level compatibility can not fully meet the requirements: the Unix era, most systems use of proprietary hardware, software developers must be responsible for your own application migration from one platform to another platform; the life cycle of each system is also very long, software developers can devote adequate resources to release for each platform binary file. However, the most widely used Linux x86 universal platform that releases are so numerous, and the development is so fast that software developers could not have issued a binary file for each release, and therefore proposes to standardize on Linux a new requirement: binary compatibility, ie binaries do not need to recompile, you can run on other distributions.

In fact, the Linux community is the first standardization efforts Filesystem Hierarchy Standard (Filesystem Hierarchy Standard, FHS), to regulate the system files, directory hierarchy storage location and system tools and procedures, such ifconfig command should put in / usr / bin or / usr / sbin directories, CD-ROM drive should be mounted to / mnt / cdrom or in / media / cdrom in. These demands eventually work together to promote the birth of the Linux Standard Base (LSB) project.

LSB is currently FSG (Free Standards Group) one of the most active working group whose mission is to develop a set of standards to enhance the compatibility of the Linux distribution, so that a variety of software can be well compatible to run on LSB standard system, which can help software vendors develop better products on Linux systems, or existing products to Linux systems.

LSB to SUS and POSIX standards, and in other areas (such as graphics) in some standard source code was expanded also increased define specifications for the binary executable file format, which tries to ensure that the application source code and binaries on Linux file compatibility.

LSB Profile

LSB Linux is the de facto standard in the field of standardization, its icon (see Figure 1) very vividly describes their mission: the development of standards for Penguin (Linux) on behalf of freedom. After a three-dimensional shape and a standard set of penguins, software developers can design and cut out the pattern of colored clothes (application), so that regardless of who wore what penguins in, will be very fit.

Figure 1. LSB icon

On the basis of the existing standard, LSB developed a binary interface between the application and the operating environment, which is mainly based on the following criteria:

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

Meanwhile, LSB UNIX standardization efforts to fully absorb the experience and lessons learned, to avoid some of the problems these standards. For example, POSIX only defines a standard programming interface, but it can not guarantee binary compatibility. The standards such as OSF / 1, although like trying to solve the problem of binary compatibility, but the limit was too strict. LSB between the two reached a balance, it contains a binary compatibility layer, while eliminating local differences between POSIX and OSF / 1.

LSB of each library interfaces with each interface, and associated data structures and constants are defined, FIG. 2 shows the LSB component contained 3.1 environment. These components include developers require shared libraries (including C ++), the file system hierarchy (the FHS), object file format, and the command tools, application packages, users and groups, and the like used in the system initialization specification:

2. FIG assembly LSB specification contains

Organization

In order to ensure the good running of the project LSB, LSB using his organization to be responsible for the full operation of the entire project, including the Chairman of the Election Committee, the Executive Committee:

• Chairman: elected by the Election Committee for a term of two years, responsible for the overall operation of the LSB projects, and community representatives FSG and LSB project. The current chairman is the founder of Debian Ian Murdock ..
• Election Committee: composed of all those who contributed to LSB, is responsible for the election of the next chairman in the presidency expires.
• Executive Committee: Chairman and by the leaders of the individual subprojects and LSB
• Projects with significant contribution of people, can begin as spokesman for the LSB project.

work group

LSB project consists of several sub-projects (also known as the Working Group), are responsible for different areas of responsibility, as outlined below:

• Specification SubGroup: responsible for opening the LSB specification development and maintenance, but also for ISO / IEC 23360 (ie ISO LSB standard maintenance). Specific duties are as follows:
  • LSB specification database maintenance
  • LSB written specification
  • Development and maintenance tools needed to generate specification documents
• LSB Tools SubGroup: responsible for the development and implementation of the following subprojects:
  • SI (Sample Implementation): comply with a reference implementation of the LSB specification
  • Development Environment: application development LSB-compliant development environment
  • Application Battery: LSB-compliant sample applications, such as lsb-apache
• LSB Test SubGroup: follow the LSB specification is responsible for defining, developing some of the test suite to verify whether the user environment and LSB-compliant applications, including:
  • LSB Runtime Tests: including ANSI, POSIX, LSB-OS, threads, users and groups, the FHS, internationalization, the PAM (Pluggable Authentication Module) or the like test suite
  • LSB VSW4 / XTS5 Test: Xlib11 its extensive library of test suite
  • LSB C ++ Test: C ++ test suite
• LSB Desktop SubGroup: responsible for developing test suites and specifications relating to the desktop, to verify whether the user environment and LSB-compliant applications, including:
  • GTK libraries
  • OpenGL library
  • PNG12 library
  • JPEG library
  • Fontconfig library
  • GTK + Stack library
  • QT3 / 4 library
  • XML2 library
• LSB Future SubGroup: load LSB open up new areas, the development has been relatively mature standard can be standardized within the scope of the field but not yet covered into the LSB LSB

LSB standardization process

LSB standard for the development and promotion of pragmatic follow the principle of it he will not establish its own standards and then forcing the industry to accept, but the industry has matured in the technical specifications and standardized form of fixed and vigorously promote them, so you can more broadly accepted as suppliers and users of the software.

To a new field into the category of LSB standard, you must go through the following three steps:

1. Identification: Check whether this field has matured sufficiently stable whether ABI / API, the need for standardization, and is dependent on the field has not been standardized.

2. Research: investigate whether the upstream software maintainers are still actively maintained, the software is stable, whether with good backward compatibility.

3. To achieve: the LSB field to join the database, preparation of specifications, writing test suites, and added development environment, SI and APPBAT.

After these three steps, LSB Future SubGroup will submit it to the LSB workgroup, include it in the next version of the LSB to publish and provide external authentication service.

Authenticate

After making a good standard and the development of the test suite, in order to distinguish system or application is compatible with the LSB standard, FSG provides the LSB standard certification services. Any Linux distribution vendors and application developers can be Linux certification, certification is currently available in two ways:

• LSB Runtime Environment: LSB standard certification as a platform vendors
• LSB Application: For application developers to provide LSB standard certification

For platform providers, after LSB certification will ensure their systems are standard services provided by any compliance with the LSB standard applications can run well on their systems; and for application developers, its meaning is exactly the opposite: do not worry about portability issues own applications on the system to comply with the LSB standard.

LSB certification process includes the following steps:

• Registration: The first step is to be LSB-certified in  https://www.freestandards.org/index.php?title=Special:Userlogin  first create an account on, and to register your company and products.
• Testing and validation: using the test tools provided by LSB, test running on your system, analyze the results (for details see the next article in this series), make sure your system or application to comply with the LSB specification.
• The final audit: When you are ready to submit a formal test results, you need to sign the agreement and LSB LSB certification trademark license agreement and pay the cost of FSG required for authentication. Then FSG will have someone to test the results of the audit, if all goes well, passed the LSB certification. By LSB-certified products will be publicly released in http://www.freestandards.org/en/Products. Now Redhat, Suse, RedFlag other companies have passed the certification of LSB 3.0, LSB 3.1 certification for being in progress.

After passing through LSB certification, certified products can be labeled "LSB Certified" label were sold.

Certification Issues Report

Partial test failures may occur during the test run the tool provided by LSB, the reason may be the product itself, such as FHS standards must exist / media / directory system, and in some systems, this directory it may not exist, then it could lead to a corresponding test suite fails, the following error message:

1 2 3 4 5 6 7 8 9

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

But sometimes the testing environment may not be the problem, but the problem itself, or because there is a recognized problem but is temporarily unable to repair the system in this case does not affect the results of the test suite LSB certified. If this occurs, the tester can use this issue to LSB (http://www.freestandards.org/cert/prsubmit.php), after confirmation, LSB will be listed in the case file a waiver, and the corresponding test suite temporarily removed, and try to fix in the next version. We may also from  http://www.freestandards.org/cert/pr.php  see if the problem has been finding.

LSB's past, present and future

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 所示：

图3. LSB 主要版本的路线图

实例：lsb_release 的规范定义和实现

我们知道，在 /etc 目录中有一个文件可以查看当前系统的版本信息，在 RHEL4U3（Red Hat Enterprise Linux 4 Update 3）上这个文件是 /etc/redhat-release：

1 2	# 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：

1 2 3 4

# 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）：

表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），该包的内容如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# 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），它包含的内容如下：

1 2 3 4 5 6 7 8 9 10 11

# 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 在两个系统上都是一个符号链接：

1 2	# 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 上的结果如下：

1 2 3 4 5 6 7

# /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 上的结果如下：

1 2 3 4 5 6 7 8

# /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 命令的位置、用法、输出格式都是相同的，因此开发人员可以使用它编写兼容性非常好的程序。

Look again on both systems and related lsb_release package, we will find that there are some differences between the two, for example, there is a / etc / lsb-release file on SLES9SP3, which is followed by the stored LSB standard version, reads as follows:

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

In the RHEL4U3 we do not have this file, but the file in /etc/lsb-release.d directory and more than SLES9SP3 on:

• /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

But only to graphics files beginning on SLES9SP3. A closer look at / usr / bin / realize lsb_release we will find a list of the LSB specification compliance can be both stored in / etc / lsb-release file, or you can put in the form of a file / etc / lsb-release .d directory. So just LSB interface definitions were the norm, but not limited to the specific implementation, so that both release providers complete freedom, but also provides a consistent interface for application developers, can maximize the promotion and application.

Conclusion

Standardized Linux operating system may provide a good platform for developing applications for application developers who make applications they have developed very smoothly ported to other distributions. LSB is defined by a series of norms and standard test suites and a development environment that can help developers to more easily develop applications that comply with specifications, assist suppliers to build a more standard system. In the next article in this series, we will introduce how to use the LSB standard test tools provided to verify that the systems and applications comply with the LSB specification.

Reproduced in: https: //www.cnblogs.com/jinanxiaolaohu/p/11063419.html