Landing Teams within Linaro
by JamieBennett on Aug 05, 2010
- 1,476 views
A description of what Landing Teams do within the Linaro organization.
A description of what Landing Teams do within the Linaro organization.
Accessibility
Categories
Tags
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 0
- Downloads
- 0
- Comments
- 0
- Embed Views
- Views on SlideShare
- 1,394
- Total Views
- 1,476
* Firstly the act of hardware enablement and what that involves
* Secondly I’d like to talk a little about what a Landing Team actually is
* And lastly about what ARM’s Landing team could be focusing on and to get input from you guys on exactly what Linaro should be doing for ARM.
So basically, getting some definition of Linux software running on a selected bit of hardware.
Of course validation is also key to any hardware enablement.
At the top, a basic enablement would consist of getting the kernel booting, tailoring the boot loader if necessary, integrating device drivers if they are available and some rudimentary graphics support. That would be an unaccelerated console or maybe as far as an X session which ever is required.
Moving on to a more complete enablement scenario, these other elements would have to be worked on. Graphics acceleration is a big one, whether that be with a closed source binary component or something more open. Closely related to that is the multimedia work on codec accelerators, and generally getting media rich content running as smoothly as possible on the silicon.
Enhancements for a specific user interface or distribution along with getting other devices running smoothly such as GPS receivers and telephony radios. Power Management is always a concern on mobile device and to truly enable a piece of silicon, this would have to have specific to the hardware.
Theres a maintenance cost to not upstreaming. A vendor has to rebase, back port, forward port and generally do a whole lot of work if their code isn’t maintained by the upstream project itself. Once you get that code upstream, the responsibility for at least making sure that code compiles on future version of the project then lies with the project maintainer. There is a minimal cost to maintaining your code once it is upstream.
Getting code accepted upstream and working with the community is great PR. It shows commitment, it show a willingness to collaborate and building these relationships is key to any vendor fully leveraging open source.
And of course once your code is upstream, your number of testers automatically increases. A basic compile test will be done on very release.
Now getting your code upstream isn’t always easy.
Theres often different expectations between the person producing the patch and the project maintainers who are the gate keepers to their upstream projects. This can lead to long iterations as the patches are discussed, comments made and the patch is resubmitted. Its a necessary step as these maintainers are committing to keeping you code working as their project moves forward.
As you work more with the upstream projects, this process becomes easier.
One other problem is that upstream never stays still, which is especially true for something like the Linux kernel. This can lead you patches quickly becoming out of date which will require work to rebase on the latest version.
All distributions take upstream code, integrate it into a more stable archive and produce a distribution from this.
Buffer:
System wide Verification:
Known, stable software versions that do not change frequently throughout the enablement process
All distributions take upstream code, integrate it into a more stable archive and produce a distribution from this.
Buffer:
System wide Verification:
Known, stable software versions that do not change frequently throughout the enablement process
Landing team is a Core Unit within Linaro
Works closely with the Platform team to get vendor specific changes into the Linaro release
These patches will be integrated first into a vendor specific Linaro kernel tree with the intention of eventually folding this tree into the main Linaro ARM kernel tree once all necessary changes are made and the Linaro kernel maintainer is happy to accept them
The vendors kernel will be built using the latest Linaro toolchain to verify that the silicon works with the latest and greatest features and the team is also responsible for producing daily validation images which can be used as a basis for testing.
A number of agreed vendor specific images, or heads, can be produced to validate the silicon. This could be a netbook image, say Ubuntu’s Unity or something like a MeeGo handset.
As I said before, the landing team works to get the vendor kernel and patches in a suitable state that the official Linaro kernel maintainer will accept them. Once they are in the official Linaro tree, responsibility for the code at least building is up to the Linaro kernel maintainer.
From the Linaro kernel tree, these patches will be further worked on to get them into a mainline submittable state. The Landing Team will work with the vendor on doing this but the final push upstream will be done by the vendor themselves.