The Linux Foundation is a non-profit consortium dedicated to fostering the growth of Linux.
|
|
Book/NewABI
From The Linux Foundation
Adding New Interfaces to the LSB Specification
Moving Forward
As mentioned in previous chapters, the first few years of the LSB efforts and the initial versions of the specifications produced in those years were the the product of a core group of Linux developers with a closely shared vision. As that vision matured and both the specification and audience grew it became clear that a more formal process was needed. No longer could everyone using and developing the LSB be expected to have internalized this vision, an official process needed to be created. The process used in the early years served its purpose of quickly identifying the "low-hanging fruit" that needed to go in the core specification right away, and tolerance for minor mistakes was a worthwhile trade-off for an accelerated schedule. However, once the first official version of the written specification was released(June 2001) the audience for the standard was now much larger and was demanding that both a high quality, stable standard and additional new interfaces. A group of people interested in these goals began meeting on a regular basis to discuss them. This new group of people became the lsb-futures subcommittee of the LSB workgroup. In addition to tracking new interfaces, the group developed official criteria and processes for adding new interfaces.
The LSB effort is unique among standards efforts in that it is standardizing interfaces that were developed (or endorsed in implementation) by the Free/Libre and Open Source Software(FLOSS) communities. Most previous standards efforts were the result of industry consortiums that could often dictate the direction of the standard, despite dissenting voices. This is not to say that previous standards efforts did not try to build consensus among those involved, only that the LSB effort represents a consensus on a scale not seen before. Where previous efforts could make standards choices based on primarily technical factors, release a new version of a standard, and expect implementors to make changes to match the new specification, the LSB workgroup must hold to a different model. First consensus about the interface must be built among the community, then the interface must be implemented among the major runtime providers, and finally, and only after those steps are completed, can it be added to the LSB specification. As a way of objectively measuring these steps, a list of selection criteria was created.
LSB Selection Criteria
Candidates for inclusion in the LSB via the lsb-futures process progress, by completing a series of steps divided into three broad categories: Identification, Investigation, and Implementation. The first two are informational, and progress is made by supplying the information for tracking. If there are no blocks in these phases, the Implementation phase can commence.
Phase 1 - Identification
The following sections in 8.2.1 of this chapter describe the requirements for Phase 1 - Identification.
Demand
There needs to be sufficient demand for the component to be standardized; demand can be measured many ways. For example, heavy usage of a component in the community or multiple requests from developers. Keep in mind that, while there may be demand for many things, not all will meet the additional criteria.
License
The component should have at least one compliant implementation available under an Open Source license that also promotes a "No Strings Attached" environment for developers. This means that the developer would be able to develop and deploy their software however they choose using at least one standard implementation. This is interpreted to mean that at least one implementation is available under a license that meets the Open Source Definition, but also does not restrict proprietary usage at runtime or in development. The rationale for this criteria is very similar to that of licenses like the LGPL, by licensing under terms that allow use by all programs, the interface can be put into much wider use.
Best Practice
The candidate must represent the "best practice" in the development community for the problem it solves. It needs to have emerged as a clear de facto standard and be available on most (or all) of the major distributions.
Stable ABI/API
The API/ABI is required to be stable enough to target for standardization. The maintainers need to follow the "best practices" for ABI/API stability; they should have a proven track record for doing so, and properly resolving any issues that arise.
Dependencies Present
The candidate's runtime dependencies should either already exist in the LSB, are planned to be added, or abstracted away so that specifying their interfaces is not required. Dependencies provide insight for things that may need to be added and/or potential problems that may be encountered. Recursive dependencies should be listed and discussed before proceeding.
Phase 2 - Investigation
The following sections in 8.2.2 of this chapter describe the requirements for Phase 2 - Investigation.
Upstream Cooperative
The upstream maintainers must be committed to backwards compatibility(for some defined version) and stability. They should be willing to work with developers and distributors on providing a standard everyone can agree on and adopt.
Distribution Maintainers Cooperative
The component maintainers for the distributors should be willing to work together. They should be willing to work with upstream maintainers and developers on providing a standard everyone can agree on and adopt.
Component Versions
The upstream maintainers, distributions, and developers should be synced up on compatible versions. If not they should be willing to agree on and adopt compatible versions.
Distribution patches
If the distributions maintain any patches against the component, these could be merged upstream or dropped. Since the LSB is a behavioral standard, this is not required but could make things easier.
Internationalization
If the component interacts with the user it should, if possible, have internationalization(i18n) support and support localization(l10n) as appropriate. Lack of locale data should try to be remedied in a timely manner, although it is hard to support every locale.
Resources
Resources for working on the deliverables required in Phase 3 should be arranged. A component may be an excellent candidate for standardization but can't proceed until there are people to do the work. Depending on the candidate there may be parties who would benefit from the standardization and could reasonably by asked to contribute to the effort.
Rationale
The rationale for why the component was added and for all parts of the specification should be recorded and published. Mailing lists and meeting minutes are not sufficient, this data needs to be recorded in the specification or a separate document. Lack of rationale documentation has already been a problem with older versions of the specification, so this is very important.
Phase 3 - Implementation
The following sections in 8.2.3 of this chapter describe the requirements for Phase 3 - Implementation.
Import into LSB Database
Import the component into the LSB database as a first step for working on the spec/tests/devel/sample.
Written Specification
Development/adaptation of the written specification for that component in the proper format for integration into the LSB specification.
Initial Test Suite
Development/adaptation of the test suites for that component in the proper format for integration into the LSB test suite.
Development Components
If required, a creation of source for the stub libraries and header files for that component, in the proper format, for integration into the lsbdev environment. For simple components, these may simply be used as a cross-check against the DB-generated headers and libraries.
Final
Once a candidate has completed all three phases, the lsb-futures subcommittee will recommend it to the LSB Working Group for inclusion in the next version of the LSB. The items completed in Phase 3 will be transitioned to the Written Specification, Test, Development, Sample, and AppBat subcommittees.
Candidate Identification
As the name implies, one of the jobs of the lsb-futures subcommittee is to identify where the LSB should go in the future. This means identifying new candidate ABIs for consideration for inclusion in the standard. Several methods have been identified and used in this process.
Input from specification audience
By far the largest and most important source of new candidates is suggestions from the LSB standards audience. Given the huge number of Linux developers, there are a lot of ideas for interfaces the developers would like to see in the standard. The lsb-futures subcommittee solicits these suggestions and gathers and organizes. This organization helps to clarify suggestions (often several people suggest the same thing, but in different ways) and gauge level of demand for an interface.
Analysis of existing code
In addition to input directly from Linux developers, several methods have been identified to programatically determine the interfaces most in demand by developers.
- Linux Distribution Dependencies - By examining packaging dependencies of the major distributions we can make guesses at a what interfaces are most depended on. These packages might be good candidates for standardization.
- Linux Distribution Base Components - The packages that major distributions include in their "base install" are important and represent the collective wisdom of the user's and maintainer's of the distribution. These packages might be good candidates for standardization. A large portion of the packages in a base system are the things that make a distribution unique, but the things that don't fall into that category are often common across distributions and good candidates.
- Existing Commercial Application Dependencies - By examining existing commercial application binaries it can be determined what interfaces they depend on and the other system features they expect to have available.
Standards Ideas
The previously mentioned methods are good for identifying library interfaces but often are not helpful in identifying other things about the system that would benefit from standardization. The futures group also spends time brainstorming ideas for standards to solve these types of problems.
Some examples are additions to the Filesystem Hierarchy Standard, system services for applications to use, restructuring the standard, and helping to determine when subgroups need to be formed to go off and investigate a new area.
Candidate Tracking
In the previous sections the LSB criteria and methods for identifying potential candidates were described. Using those, the futures groups tracks the status of proposed candidates on a publicly browsable Web page.
For each candidate the status towards meeting each of the LSB selection criteria is listed along with some additional tracking data and an overall summary. This allows an easy determination of what work needs to be done for a particular candidate. As mentioned in the criteria section, once a candidate has met all the criteria it can be added to the next version of the specification.
One nice thing about this tracking system is that it allows for any potential candidate to be added, if that candidate can meet the criteria, then it belongs in the LSB. Sometimes a candidate will be added but will be blocked due to not being able to meet certain parts of the criteria. It continues to be tracked and if and when it can meet the criteria then it can be added. It makes the process more objective and protects against things being added before they are ready.
Problem Cases
In the course of tracking candidates the futures group has encountered a few classes of candidates that, while in demand, are problematic to add. The following sections describe are a few examples of this.
Linux Specific Requests
One of the most requested category of interfaces are those that are Linux kernel related. In particular, developers would love to have a kernel module API. This is problematic for two main reasons. The first is that it fails the criteria that requires support of the upstream developer. The Linux kernel community has explicitly stated that they will not commit to an ongoing standard interface because they want to be able to change that interface as needed when it makes sense. The second is that the LSB has yet to define anything kernel-related and would prefer to keep it that way in order to not preclude runtime implementations on non-Linux systems.
Interpreted Languages
Another common request is for interpreted languages such as perl, python, and tcl/tk. The main reason that these are currently blocked is the lack of a formal standard that the LSB can reference. Most of these languages have stable interfaces, what's needed is a formal standard specification that the upstream maintainer will stand behind.
License Issues
Some candidates fail to meet the LSB license criteria due to the fact that the only existing implementation is under a license, such as the GPL, that require anyone using that interface to also release the source code to their software. The LSB seeks to maximize the numbers of people using Free Standards and FLOSS. The license criteria was selected as a way of providing a "no strings attached" environment. If the only viable implementation of an interface is licensed under the GPL or a similar license, then the LSB would become uninteresting to those not willing to use restrictive licenses. This is essentially the argument for the existence of licenses such as the LGPL, by licensing under terms that allow use by all programs the interface can be put into much wider use.
For example, the LSB futures group is tracking two windowing toolkits, GTK+ and Qt. GTK+, and is currently proceeding as it is licensed under the LGPL and requires the normal efforts to add to the specification. Qt, on the other hand, is currently blocked since the only implementation is covered by a dual license, either QPL(GPL terms, requires release of source) or commercial. This has generated quite a bit of discussion on the mailing list. Qt continues to be tracked and if an implementation that meets the license criteria becomes available, it will be unblocked and can proceed.
How to get your favorite interface added to the LSB
The LSB processes are designed not to get in the way of people wanting to contribute. If a developer has a candidate that they would like to see added to the standard, they can request that it be tracked as a candidate. If the work gets done to make the candidate fulfil the criteria, then it can be added. The only thing limiting when something can be added to the LSB, is how quickly the criteria can be fulfilled. The LSB workgroup would love to see additional interfaces added and encourages all to participate.