UDS Discussion

This is meant to be a highly interactive session.

If you want to make a product, does Linaro Ubuntu LEB, ALIP, Nano, make a good starting point?

  • How could the images be improved to make them a better starting point? What is the best way for a product developer to get started using Linaro?

For those creating their own images because they've outgrown the reference images, doesn't it make sense to:

  • - make live-builder output final dd-able image (complete kernel + rootfs) - evolve live-builder so it is able to run cross platform - other ?

Is it useful to :

  • Include/point to information about how to:
    • startup, shutdown
    • tune for performance
    • customize kernel
    • customize hwpack
    • customize installation
    • theme user interface
    • pointers to setting up test environment, with outline of current code coverage.
    • problem specific docs
      • boot time
      • network
    Would it be useful for linaro to give guidance on functional choices for product?
    • what packages to use for:
      • audio
      • video
      • user interface configuration such as touch screen
      • how internationalization support works and what's available
        • basically give problem X, use package(s) Y
    • what graphical toolkits to use
    • what languages are available and positive / negatives associated with those choices

User Stories


This is a work in progress.

Blueprint: https://blueprints.launchpad.net/linaro/+spec/linaro-platforms-o-improve-head-start


In 11.11 the following Priority is set: (as taken from https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Platforms)

  • Focus on making Linaro Evaluation Builds and developer images a quick starting point for product builders that want full member board enablement as well as Linaro improvements in one shot.

In Technical Requirements the following has been created:








Linaro for product builders and innovators


Android LEB


Provide a Linaro optimised build of Android



Android Toolchain packages


Provide Linaro Toolchain and Platform code ready for consumption by android product builders



Ubuntu LEB


Provide and refine a Linaro optimised build of Ubuntu.

Developer Platforms


Nano image


Provide and refine a 'small as functionally possible' image that can be used for simulator models. Other build methods are to be explored to produce the smallest possible image

Developer Platforms


Device Tree enablement


Package and test device tree support from the WG's, integrate support into the LEB images. This includes u-boot, kernel and build-tools work.

Android, Developer Platforms


Experimental Generic HWPACK


Experiment with providing hwpacks that can be shared in Ubuntu and Android

Android, Developer Platforms, Infrastructure

Getting from there to here

When I was young, when racing my Dad on foot, he'd say go up the block a bit and start from there and I'll start from here so that I'd get a head start on our race back to the house. Two things must be observed from this race:

  1. The starting point was established.
  2. The ending point was established.

When building a product, you need to know what parts you have on hand (your starting point), what you'll have to build yourself (the length of your run) and what the end goal of the product is (the end of the race).

Our head start is our open source software and it's improvement. To be effective we must communicate what Linaro has and likewise we must listen to what the product builder needs.


If we can say we have a wired communications stack that should run on a list of chipsets, have we given a product needing that capability a head start? Put yourself in the Product builder's shoes. If you've given no level of confidence in the capability, to make use of that component, the product implementor will have to fully test it. Further if there are defects found now they have to take ownership of the code and undertake a voyage of discovery in the code base that will have to include interaction with a community that might be foreign to them. Depending on the issues involved this investment of effort could be a small cost to that head start or could completely blow away what could have been a head start but is now a head ache and now an negative experience with open source.

Contrast that to, Linaro has a wired communications stack supporting ethernet over the following chipsets, with some set of capabilities, with some defined level of reliability, and defined level of test for a product needing that capability. The Product builder sees the menu of what's available, the code in question, caveats, the test harness for the code. Now the product creator can compare what they want to accomplish in the product with what is provided, and tested. The difference becomes the areas for which their product team is responsible. The product creator has the ability to communicate with Linaro and suggest areas where to close the holes and thus help the product along as well as other products.

Either way Linaro doesn't officially support the code. Linaro doesn't automatically extend the code. However Linaro would more clearly define the starting point, the pitfalls and present a willingness that if appropriate the code be extended, optimized or fixed.


IDIC stands for Infinit Diversity in Infinite Combinations. In the Linux kernel and vast array of open source software that runs on this kernel, we have the vary embodiment of this term. IDIC unfortunately is a tough sea to navigate when you're not an expert in all the combinations.

Linaro wasn't created to design products. It wasn't created to support products. Linaro can however identify and make the various open source parts that go into a product better. Linaro can help to push information to product designers to make better informed decisions.

Currently Linaro supplies four images, Nano, Developer, ALIP and Ubuntu Desktop. Are these starting points for a product? I assert no, they aren't.

Step back and ask yourself, how would a product builder make a product using Linaro as a starting point?

They would have to identify some number of packages that addresses functional goals of the product. They would have to identify the kernel. They probably have to configure the kernel as appropriate for their hardware. They would have to understand where the configuration points are for the user space packages. They would have integrate all this into a build, build it with something like live-builder. They would have to test individual packages as well as the whole. Along the way bootloaders won't just work. The kernel probably won't just work. Graphical hardware might not just work. User experience probably won't be consistant. Etc.

There's a lot of problems to solve here to reach the goal of an end product. Frankly it's fairly confusing and from Linaro resources as well as external to Linaro. This adds to the complexity of using Linaro as a starting point to a product and affects time to market negatively.

What are the parts a product builder should use? The ubuntu software catalog indicates what packages are there but it doesn't say what packages are the ones to use. It doesn't give direction on where the configuration points are. That's no statement on reliability. It doesn't address uniquely embedded issues such as impacts to boottime, memory footprint while the application is running, and so on.

Building Products

  1. Linaro needs give better direction on how to use Linaro as a starting point.
  2. Linaro needs to better identify what parts there are for product creators to use.
    1. Those parts need information about configuration that would be important to product creators.
    2. Those parts need information about reliability, how to pick up and internally test the code to replicate open source testing.
    3. Those parts need information about when there are issues, what courses of action are available without the product owner bearing the full burden of the issue.
  3. Linaro needs to give better direction on how to assemble all the pieces into a functional whole.
  4. Tangential Linaro needs to identify where the barriers that are adding to the product creation cycle. We should label those issues by the estimated time they add.
    • Ex: 1 Second boot. Is that a week, month, months investment by a product creator to get that?
    • Ex: IO hangs involving SD. Week, month, months investment to fix

Functional Modules

The product builder ought to have a selection of recommended parts, the functionality if you will that they have to choose from. Let's call these Functional Modules for the moment or a software roadmap of sorts. Let's not give them everything Linux can do or everything that can be found in the Ubuntu software catalog, but defined data points from which to make informed decisions as well as a point of communication back to Linaro with issues that may warrant our attention.

A Functional Modules documents

  • What it does.
  • What the known limitations are.
  • What the configuration points are.
  • It addresses how it's validated.
  • How does support work?
  • Does the module impact boot time? If so by how much?
  • What is the memory/power/cpu footprint when the module is running?

A functional module should be "installable." It should handle it's dependencies. It should handle it's conflicts. Sometimes it might be a package, but often times it will be a collection of packages.


  • Application Logging
  • Media Player
  • Graphical Environment with Gesture support for devices without a keyboard

It should be possible to combine a number of functional modules with suggested recipe that might cover an interesting vertical market such as a tablet, mobile phone, entertainment system.


At the moment Linaro gives no formal direction on how to put a product together in a reproducible manner. We have our own internal tools to create hwpacks and live-builder to build images. These are tools with sharp edges that take experience to utilize.

For a product builder, something is needed. Such a tool could/should also include a mechanism to include software that is internal to the product builders company.


It can not be ignored that Xcode plays a significant role as a productivity tool for iOS. Likewise, for Android, were Eclipse not there making end user applications it would be a significant issue.

For Android based products, Eclipse need not be reinvented. For Linux based products however, Eclipse or some development environment that supports end user application development is important and Linaro needs to take a position if not advance the state of the art.


Product teams need to test their product. This includes the code pulled in from Linaro or the community as well as their own code. Linaro should take steps to enable product level test through demonstrating it's own test, documentation best practices, and enable product creators to replicate it.


  1. The creation of a Catalog of Functional Modules for product developers to use Linaro as a starting point for their products
  2. The creation of a Product Build tool that allows product developers to use Linaro Functional Modules as the building blocks for their product as well as giving them a reasonable easy method for product developers to add their own software.
  3. Linaro needs to document the use of a development environment be it Eclipse or akin for application developers as appropriate for the end user interface in use. Gnome / kwin / Android / Chromium have unique requirements and product developers need good guidance for the environments that Linaro would deem important.
  4. Linaro should maintain by example a good test environment for the software it is focused on as use that as an example with clear instructions as to how to replicate that validation environment in a product developer's Lab.
  5. Linaro should maintain a "Product Delay" list of issues that product developers can interact with. This is a list of rough edges to be worked should roughly summarize the delay introduced to a product that would have to address this issue by themselves. Solves issues should be used as a showcase of Linaro's positive impact.


Internal to IBM I helped create and for a time ran a team of engineers that created a collection of Linux and open source technologies for use in product. We couldn't predict what problems had to be solved but we had a fairly good handle on what base capabilities were important through our own knowledge and interactions with users of our technology who might give us direction from time to time. Providing good starting points for product creators using open source technology is familiar territory ;-)

Platform/FunctionalModules (last modified 2011-05-11 09:29:40)