Difference between revisions of "Open Embedded"

From eLinux.org
Jump to: navigation, search
m (Bot (Edward's framework))
 
Line 64: Line 64:
 
out of it.)  So, outside contractors seems like the better way to
 
out of it.)  So, outside contractors seems like the better way to
 
go for now.
 
go for now.
 +
 +
[[Category:Development Tools]]

Revision as of 05:59, 14 July 2007

Table Of Contents:


Description

Open Embedded is the name of a project which seeks to provide embedded linux distributions, built from scratch.

Rationale

While the distribution used for most embedded systems has many custom elements, there are significant portions of the software on consumer electronics products which could be standardized and utilized from the same source.

Open Embedded may represent the closest thing there is to a de-facto standard embedded distribution of Linux.

Resources

Projects

http://www.openembedded.org/

Specifications

There are no CELF specifications related to Open Embedded.

Downloads

Patch

- [Patch for 2.6.xx is *here* (often, the Patch Archive)]

Utility programs

[other programs, user-space, test, etc. related to this technology]

How To Use

See the Open Embedded wiki, at: http://www.openembedded.org/cgi-bin/moin.cgi

How to validate

[put references to test plans, scripts, methods, etc. here]

Sample Results

Case Study 1

Case Study 2

Future Work/Action Items

Here is a list of things that could be worked on for this feature:

- 

I met with Phil Blundell and Tim Ansell at Linuxconf Australia and discussed some possible ways the forum might sponsor Open Embedded. Here are some ideas:

- create an installer, which automatically copes with weird distros
(I had problems getting OE installed, but then I use Mandrake)
  - it should validate that all required packages are installed,
  and if not present, install them
    - OE has a somewhat long list of pre-requisites
- sponsor a conference/retreat of the core OE developers
- do nightly builds (and testing?) of various full-distro recipes
- do improvements to bitbake to solve the memory/performance
problems.
  - need to identify if these are python issues (dependency graph
  memory consumption seems to be)
- try to make bitbake less fragile
  - have a way to freeze/sign a recipe collection for a known-good
  distro?
- canonicalize workarounds to issues caused by autoconf badness
(inability to support cross-building)

Tim and Phil both said that contract money might not influence their contribution levels (they are maxed out now). Changing their focus with money might be detrimental (it might just take the fun out of it.) So, outside contractors seems like the better way to go for now.