LSB 2.0 Structure
March 2004
Introduction
Starting with Version 2.0, the LSB specification is divided into a modular structure. This is reflected in the source structure of the specifications and the documents produced by that source. This document was created to help explain this new structure.
Definitions
First we need to define some terms that will be used in the rest of the document.
What?
What is a functional area?
A function corresponds to the smallest standards unit with reasonable justification for it's individual existance. To divide it into smaller units would not make sense since implementors that interface would implement all the smaller units anyway. Often the justification for a function will be the possibility that it will be useful for implementors who are targetting only some portions of the available standards in an a la carte manner.
What is a specification module?
A specification module is a unique collection of one or more functions that has value for a certain group of runtime implementations. To borrow a business term, a specification module is specific to a "vertical market". specification modules can range from informal concepts to certified standards.
What is a product standard?
A product standard is a unique collection of one or more specification modules that is used for compliance testing and certification of runtime implementations.
What is compliance?
A runtime implementation that has implemented interfaces of one or more of the functional areas and/or specification modules, can run tests suites that test their implementation to ensure that it has implemented the interfaces correctly. If so it is said to be compliant.
What is certification?
Certification is the official process of testing the compliance of a runtime implementation of a product standard by a Certification Authority who can then assert that a tested implementation is compliant with the standards within that product standard, usually involving some sort of brand or trademark.
What is a dependency?
Some functions have dependencies on interfaces contained in other functions. While a hard dependency may not exist, implementors of such a function would need to provide the dependencies required either by implementing the dependent functions or at least making sure the required interfaces are available.
What is a runtime implementation?
A runtime implementation is a piece of software written by an implementor that strives to implement one or more of the functional areas and/or specification modules, in order to achive compliance with a product standard and possibly seek certification for that software. One thing to keep in mind is that runtime implementations aren't necessarily always the common cases that spring to mind, interfaces can oftern be implemented in non-traditional environments as a way of providing a compatibility layer for software porting.
What is meant by "a la carte"?
From WordNet (r) 1.7.1 (July 2002) [wn]:
a la carte
adj : (of a restaurant meal) having unlimited choices with a separate price for each item [ant: {table d'hote}]
n : a menu having individual dishes listed with separate prices
adv : by ordering items listed individually on a menu; "we ate a la carte"
By implementing standards as individual independent functions, implementors can pick and choose those they want to implement. In some cases it might be hard for them to implement a full specification module but they could implement a few pieces of it and still benefit from the standards in those areas.
Who?
Who is a developer?
The term developer can mean, but is not limited to, an independent person, a group of independent people, or an Independent Software Vendor(ISV) that is developing software intended to be deployed and run on a runtime implementation.
Who is a implementor?
The term implementor can mean, but is not limited to, an independent person, a group of independent people, or an Independent Software Vendor(ISV) that is developing a runtime implementation.
Who is a workgroup?
A workgroup is a standards body that produces functions, which are often part of specification modules. These specification modules may be used in product standards and have a certification program being run by the FSG. Workgroups may be Free Standards Group groups or possibly associated with other Community and Industry groups.
Who is a Certification Authority?
A Certification Authority is the organization selected by the to run the certification program.
Product Standard Descriptions
Specification Module Descriptions
LSB-Embedded
The minimal set of interfaces that a developer targeting a system would expect to be able to find. This specification module is intended for embedded system runtime developers. This specification module is not currently included any Product Standard, but one could be added to one if there is demand. In addition this module currently includes some things that may not be present in a version used for a Product Standard.
LSB-Core
The set of interfaces that developers targetting any general purpose Linux runtime. This includes only the basics for runtime environments.
LSB-Graphics
This module provides graphics interfaces such as The X Windows System libraries and the OpenGL library. It is to be used in conjunction with the LSB-Core module.
LSB-OpenI18N
This module provides additional OpenI18N commands and interfaces beyond what is included in the LSB-Core. It is to be used in conjunction with the LSB-Core module.
Functional Area Descriptions
Key
Function: Function name
Workgroup: FSG workgroup that owns the function
Contents: Sections of the current 1.9 spec that would be in this function
Dependencies: The highest function this function depends on(may include/imply dependencies recursively).
Purpose: The purpose for the function
Rationale: Why it warrants it's own function
Existing Function
Function: ELF
Workgroup: ELF
Contents: Object Format and Dynamic Linking
Dependencies: None
Purpose: Describes Object Format and Dynamic Linking
Rationale: This information is not Linux specific and is used in other systems such as commercial Unixes and *BSD. There may be implementations that choose to implement this function and nothing higher. Example: elevator controller
Function: Execution Environment
Workgroup: FHS
Contents: Execution Environment
Dependencies: None
Purpose: Describes Filesystem Hierarchy and Details
Rationale: Like the ELF function, this information is not Linux specific and is used in other systems such as commercial Unixes and *BSD. This information is independent of object format, libraries, etc. There may be implementations that choose to use this function and not any others.
Function: Base Libraries
Workgroup: LSB
Dependencies: ELF, FHS
Contents: Base Libraries
Purpose: Core set of libraries to support a C and C++ runtime enviroment
Rationale: There may be implementations that only use this function and it's dependencies for things like embedded devices that provide their own interfaces or may not interact with the user at all. Example: Tivo TV set top box
Function: Utility Libraries
Workgroup: LSB
Dependencies: Base Libraries
Contents: Utility Libraries
Purpose: Additional commonly used utility libraries
Rationale: There may be implementations that, similar to the Base Libraries example, only need a core runtime but in addition use some of the common utility libraries for compression(libz), user interface(libncurses), etc. Example: Network Music Jukebox
Function: Multiuser Environment
Workgroup: LSB
Dependencies: Utility Libraries
Contents: Commands and Utilities, Standard Shell, and Users & Groups
Purpose: Things you'd expect to find on a multiuser system. Provide a reasonable set of commands and a shell for developers to be able to utilize. These are provided primarily for developers and only secondarily for runtime users. Define how users and groups are expected to work and reserved ranges.
Rationale: The possibility exists of implementation on non-ELF/FHS systems so the function can stand on its own.
Function: System Initialization
Workgroup: LSB
Contents: System Initialization
Dependencies: Commands & Shell
Purpose: Define how the system initializes itself and how applications are expected to interact
Rationale: The possibility exists of implementation on non-ELF/FHS systems so the function can stand on its own.
Function: Packaging
Workgroup: LSB(Current) / Packaging(Future)
Contents: Package Format and Installation
Dependencies: System Initialization
Purpose: Define the LSB package format
Rationale: The possibility exists of implementation on non-ELF/FHS systems so the function can stand on its own.
Function: Graphics
Workgroup: Desktop
Contents: Graphic Libraries
Dependencies: none
Purpose: Define a base set of low level graphics libraries
Rationale: Not all implementations will want graphics.
Function: OpenI18N
Workgroup: OpenI18N
Contents: Interfaces beyond what is already included in the other functions
Dependencies: Base Libraries, Utility Libraries, possibly more
Purpose: Define a set OpenI18N specific commands and libraries.
Rationale: Some runtimes will need more internationalization than it provided by the existing functions.
LSB 2.0 Structure
Below is a visual representation of the new structure. Each box represents a function. Functions are colored according to the Workgroup that maintains them:
ELF | FHS | LSB | Desktop | OpenI18N. Functions are stacked according to their dependencies. The arrows indicate what functions in the stack are included in that specification module.
FAQ
What are the goals of modularization?
- Increase the standards audience(and thus the audience of the runtimes implementing those standards). By making the ways to implement the standard more flexible we can address audiences that we couldn't previously. The larger the standards audience the larger the benefit for all. We want as many people as possible using the standards, even if they are only using a small part of it.
- Make implementation of standards easier
- Independent groups working on functions/modules makes it easier for more people to participate
- Independent functions/modules allows for independent release schedules. As they mature they will need fewer and less frequent revisions.
- Converting our structure to a more modular one will give us flexibility to move things around and regroup as needed. If the functions/modules workload becomes too much for a workgroup a functions/modules and it's infrastructure(spec, tests, etc) can easily be spun off to a new workgroup.
There will be a large number of possible functions/modules combinations, won't this mean many fragmented standards?
The existence of almost limitless combinations of functions/modules does not imply that we would have recommended specification modules or certification programs for each of those combinations. We will be very selective in the modules we choose to pursue, and those according to a "Standards Creation Policy" document(yet to be written) that would have strict criteria for modules creation. See the "requirements" question below. The module flexibility allows us to address the combinations that we couldn't before and only increases the audience for our standards. It also allows others to better leverage our work.
What specification module(s) will applications target?
Because modules will target a certain niche and we require modules to be unique, there should be a logical modules for the application to target. In cases where an application may want to target multiple modules, then the application may be able to target the least common denominator of modules or module groups so that it would work on both modules. FIXME: This needs some discussion. We don't yet know how function/module dependency is going to work.
What if distro foo certifies for module A and distro bar certifies for module B?
Similar to the question above, applications wanting to be able to install on both would need to target the lowest common denominator and have a way to indicate that dependency.
For my runtime product I only want to implement certain functions(or modules). How do I do that?
We need to write a "Using standards a la carte" document.
I want to create new standards on top of existing functions/modules. How do I do that?
FIXME: This will be addressed by the yet to be written "Standards creation policy" document.
What are the requirement for a new function/module?
FIXME: This will be addressed by the yet to be written "Standards creation policy" document.
FIXME: We probably need to write a criteria list
- need to be unique and not conflict or reinvent other functions/modules
- should not place unnecessary demands on the functions/modules on which it depends
- need sufficent demand
- etc.
FIXME: Questions without answers
How will function/module dependency work?
Both from a runtime and application perspective.
Last updated: Thu, 11 Mar 2004 02:33:17 -0500
