LSB Plenary 2014
The Linux Standard Base project (LSB) is holding a plenary session (or face-to-face, if you prefer) during the Linux Foundation 2014 Collaboration Summit. Our sessions will take place on Thursday 27 March, in Salon F.
To allow for remote attendees, we will also be including participation via Google Hangouts. Anyone wishing to participate who cannot use Google Hangouts for some reason should contact Jeff Licquia for alternate arrangements.
Any last-minute changes will be noted here. Both in-person participants and remote participants are encouraged to keep an eye on this section for any news about our schedule.
2014-03-21: Initial schedule posted for review.
2014-03-24: Per conversation with Kay, increased her time, and cut from "other architectures" to match.
8:30 am: Will be setting up Google Hangout soon. Google Hangout participants, please check into IRC.
1:40 pm: Changing the schedule based on the morning's conclusions.
March 27, 2014
|9:00am - 9:30am||Welcome, current status, overview of agenda|
|9:30am - 10:30am||"Making the LSB More Effective" -- Kay Tate|
|10:30am - 11:00am||Time-based release schedule|
|11:00am - 11:20am||Profiles -- server, others?|
|11:20pm - 2:00pm||Break and Lunch|
|2:00pm - 2:30pm||Next steps: ISV communication, generating the list, shopping the new direction|
|2:30pm - 3:30pm||Standards enhancements: what to do, what schedule|
|3:30pm - 3:50pm||Architecture issues: ARM, 32-bit architectures, others|
|3:50pm - 4:30pm||Break|
|4:30pm - 5:20pm||Wrapping up, miscellaneous topics|
Details for the specific sessions, notes, etc. Besides acting as an agenda, let's take notes here on the actual discussion.
"Making the LSB More Effective"
Kay has been thinking about this problem. How do we make the LSB an attractive project to support and use?
Time-based release schedule
Instead of working off a feature-based release schedule, the LSB should move to a time-based release schedule, focusing on smaller, more frequent updates and a process for adding features which allows features to go in as they are ready.
Infrastructure: getting new standards in
Our current import scripts are error-prone and difficult to use, which inhibits people from contributing. How do we fix this?
Profiles: server-only, others
Current LSB requires entire LSB to be implemented. In particular in the ARM server case, this does not make sense.
"Small Word" architectures
There are a few issues to discuss with the 31/32-bit architectures. The main problem: native support for "small word" architectures is going by the wayside, with these architectures supported in the normal case on a "big-word" architecture. So far, we assume all architectures are fully native; on our current course, that will be no longer true in a short time.
- Redoing "small-word" architectures: Currently, our architecture support assumes that every architecture is natively supported. For the "small-word" architectures (x86, ppc32, s390), this is becoming less true. Do we drop "native" support, and make them a mode of the 64-bit architectures instead? Or something else?
- PPC32 ABI: Deprecate PPC32 ABI. Rationale: there are no distributions directly supporting. Though the minimum requirement of two distros is not met, ABI itself can still run on a related distribution, PPC64, which has been the basis for continued support so far. Deprecation opens the door for removal in another two cycles.
- S390 ABI: Deprecate S390 ABI. Rationale: there are no distributions directly supporting. Though the minimum requirement of two distros is not met, ABI itself can still run on a related distribution, S390X, which has been the basis for continued support so far. Deprecation opens the door for removal in another two cycles.
- X32 ABI
- Add support for X32 ABI. Rationale: per various sites (unclear which is the definitive source), "x32 ABI (x32 application binary interface) is an application binary interface project for Linux that allows programs to take advantage of the benefits of x86-64 (larger number of CPU registers, better floating-point performance, faster position-independent code shared libraries, function parameters passed via registers, faster Syscall instruction... ) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers." X32 ABI added to LSB would allow conforming binaries to use this ABI.
- It is not clear there will ever be a native distribution, so this might be a "hosted ABI" to be run or a 64-bit distribution as are PPC32 and S390 today.
Other architecture changes
- ARM ABI: Add support for a 64-bit ARM LSB. Rationale: this is one of the few architectures experiencing new growth. There is not believed to be enough common ground among 32-bit ARM to build a useful LSB, but a 64-bit LSB could help keep that ABI from diverging.
- IA64 ABI
- Deprecate IA64 ABI, for removal in a future LSB. Rationale: minimum requirement of support by two "interesting" distros no longer met.
- Alternative: Drop IA64 ABI immediately. Rationale: as above, plus - since no distribution can possibly support this ABI on LSB-next, it should not be included, "deprecation" does not make sense. Instructions would be "use LSB 5.0 tools or earlier for IA64 support". Actually, it is not clear any distribution will support 5.0 either, so maybe "use LSB 4.1 tools or earlier".
- POWER8 endian changes: POWER 8 will reportedly allow little-endian architectures, and it's rumored that the Linux distributions will move that way. What does this mean for the LSB?
What should be the highest priorities for the next version of the LSB?
The presentation by Kay and the "issues" raised focused the discussion on the future of the LSB as we know it. This discussion proved to be very successful and made the rest of the agenda obsolete. The high level executive summary:
- LSB 5.0 has top priority and we want/need to get it out of the door ASAP to allow Enterprise distributions releaseing in 2014 to certify.
- LSB 5.0 will be the last specification of its kind. No follow on releases LSB 5.1 or LSB 6.0 are planned. The 5.0 specification will enter maintenance mode, i.e. we accept bugs and will fix them potentially leading to LSB 5.0.1 etc.
- The working group will focus on a new approach that will still have distribution compatibility at it's core. Rather than focusing on producing voluminous specifications we will focus on identifying cross distribution issues that would prevent ISVs from treating Linux as one platform.
- The working group aspires to become the place for distribution vendors and communities to discuss cross distribution issues.
- To facilitate collaboration and this new focus we will set up a new project on Github
Detailed meeting minutes: