Yocto Features

From Yocto Project
Jump to: navigation, search

This page captures the requested features for the Yocto Project 1.0 release.

Yocto Project v1.0 will be released in April 2010.


Process for Entering New Feature Requests

  • Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
    • Suggestion: start by copying an existing request as a template
  • Give the feature a short, descriptive name
  • Provide a one or two sentence brief description of the feature
  • Set the priority as appropriate (see the legend below)
  • Set the Status to "Review"
  • In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
  • In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
  • Preview your Entry to make sure it looks ok and then save it


Priority: 1 = Must Have, 2 = Nice to Have, 3 = Optional

Status: Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release

Yocto Linux Core Features

Features common to the Yocto Linux project

Feature Name Description Priority Status Source Comments / Bugzilla Links
Placeholder feature name Placeholder description of the feature 31 Review name Comment

Poky Features

Features of the Poky build system

Feature Name Description Priority Status Source Comments / Bugzilla Links
Poky Image Creator A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the

selection is made, it goes off and bakes you an image which is then presented to you.

Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes.

2 Review rpurdie Enhancement
Fetcher Overhaul The highlight summary would be merging of the fetch and unpack tasks.

This would mean we could put git checkouts directly into WORKDIR/git and do fetching/handling of SCM based checkouts much more efficiently as we'd no longer have to tar/untar but could do a referenced clone. WORKDIR could be made a directory without the revision in the name so when the version increments, the WORKDIR can just be updated by the SCM and rebuilt.

I'd propose we rewrite the fetcher code as lib/bb/fetch2, then switch poky over to use it, leaving the fetch directory around until we can get to it.

Related to this task is storing SRCREV knowledge from the recipes at parse time for access by the bitbake core, there is an open bug about this enhancement. We can then nuke the central revisions file in the distro directory which users hate.

Also, the fetcher should be checking the validity of what it does - checksums for everything in SRC_URI except file:// and scm urls.

2 Review rpurdie Enhancement
OpenEmbedded/Bitbake Upstreaming We firstly need to review where we are and where OE is. We then need to

make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in "dealing with OE" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate.

The key thing to remember is we need to keep the architectures compatible.

The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them!

2 Review rpurdie Enhancement
Bitbake multi-threaded parsing Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single

task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it.

2 Review rpurdie Enhancement
Performance Analysis and Enhancement I'd like someone to instrument a green release build, see where it

spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up:

a) pseudo b) checksums/signature code c) exec() vs fork for executing tasks d) task based prebuilds increasing disk usage e) rpm dependency calculations f) using rpm vs. ipk

but I may be wrong and there may be others. We need numbers.

2 Review rpurdie Enhancement
libtool sysroot option libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. 2 Review rpurdie Enhancement
Handle old versions in WORKDIR an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful 2 Review ktian1 Enhancement
package config option enhancement currently config options of a package are only known by manual check. It's not convenient for recipe owner or distribution developer to manipulate available options. So this enhancement may run "./configure" to parse the output and then convert into bitbake variables which can be then shown on the console or manipulated in the Poky Image Creator. The manipulation of those config options then becomes normal variable assignments in the recipes. But this may have dependencies on do_configure task since ./configure may not be there in the 1st place which also means that w/o fetch/unpack this feature is not available which may need more thought later. 3 Review ktian1 Enhancement
enable KVM with qemu today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. 2 Review ktian1 Enhancement
interactive targets To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c linux-menuconfig. 2 Review bruceashfield Enhancement
environment variables for kernel builds switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. 2 Review bruceashfield Enhancement
kernel development layer The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. 2 Review bruceashfield Enhancement
Dependency packages rebuild/clean It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. 2 Review dongxiao.xu Enhancement

Distribution / components

Feature Name Description Priority Status Source Comments / Bugzilla Links
Distro Audit The 1.0 audit needs to:

a) Make the licence checksums fatal if not present b) Make sure all SRC_URI components have checksums too (fatal if not) c) Update to new versions as needed d) audit package documentation output

2 Review rpurdie Hygiene
License Update For each of the licences we support, I'd really like to have a licences

directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field.

2 Review rpurdie Hygiene
Toolchain Bootstrap Process The toolchain as it bootstraps overwrites files like libc.so and

libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled.

2 Review rpurdie Hygiene
MACHINE specific sysroots Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). 2 Review rpurdie Hygiene
Zypper/RPM Re-Architect the Zypper/RPM interaction 1 Review sgw Functionality
Distro Update Complete the Package update/upgrade process with World package and check for additional updates of our current list. 2 Review sgw Hygiene
LSB Sanity execute LSB Test and improve passing rate and document failures with clear understanding 2 Review sgw Hygiene
Review & Fix Standards Tests Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures. 2 Review sgw Hygiene
Package Developer Tools Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. 2 Review sgw Easy of Use
FOSSology This may be similar to License Update above, but start to use FOSSology to track licenses. 2 Review sgw Hygiene
Package Website Complete the work the intern has started on generating the distro tracking information and get it out on the external site. 2 Review sgw Hygiene
kernel version keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. 3 Review bruceashfield enhancement
Bluetooth UI support Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. 2 Review dongxiao.xu enhancement
Connman-gnome enhancement features Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, VPN, etc. 2 Review dongxiao.xu enhancement
Java Running Environment support Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. 2 Review criping enhancement
Qemu mem/disk size can be adjusted For application developer, I feel it's hard to give a default qemu mem size. And also, for non-unfs mode, it's

also hard to limit the free space size. We can provide several options for different archs maybe. And also it may not be very difficult to export an interface to qemu creator UI in SDK plugin. In the long run, maybe we can also provide some selectable package in qemu so that user could choose different qemu (tcf-qemu, java qemu, c/c++ qemu, qt qemu, etc).

2 Review criping enhancement
security updates we need a dedicated person to scan and apply critical security updates to the distro. Actually MeeGo team already has a similar process with some developed scripts which may be leveraged 2 Review ktian1 enhancement
mklibs mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. 2 Review Nitin Kamble enhancement
perl upgrade perl is the most cross un-friendly recipe pending upgrade. 2 Review Nitin Kamble enhancement
rootless X rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. 2 Review yuke enhancement
i18n support internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. 2 Review yuke/qing enhancement

The following is a list of supported hardware.

Supported Architectures

Architecture Description Priority Status Source Comments / Bugzilla Links
Intel Platform Support The product will produce images that will support CRBs derived from the Tunnel Creek platform. This includes support for the IEGD graphics driver. 2 Accept davest Basic ECG support

Supported Targets

Target Description Priority Status Source Comments / Bugzilla Links
new arch Add here new targets validated and supported with BSPs 2 Review davest Basic hardware support

Tool Development and SDK Features

Tools that are part of the Yocto Linux project and the Software Development Kit

Feature Name Description Priority Status Source Comments / Bugzilla Links
SDK Installer Currently you have to download an SDK toolchain, a qemu kernel and a

qemu rootfs, then merge these things all together. Instead we should separate these out into the following blocks:

  • SDK core (inc. installer)
  • 32 bit native tools
  • 32 bit compiler [for each arch]
  • 64 bit native tools
  • 64 bit compiler [for each arch]
  • Target kernel+rootfs [for each arch]
  • Optional extra lib 'packs' [for each arch]

The target roofs would be used both by qemu *and* as the SDK sysroot, there are some privilege issues that would need resolving there (install into /opt/poky/sysroots, but copy then use from the users's homedir?)

The installer would be a script/UI (ncurses? installshield? just checking if you're awake!) that would tell you which tarballs needed to be downloaded and extracted into /opt/poky.

2 Review rpurdie Enhancement
SDK Version Control If we can expect that yocto SDK has lots of release

in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred.

2 Review criping Enhancement
Provide qemu management UI In current eclipse plugin, QEMU settings are put together with

project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration.

2 Review criping Enhancement
QT plugin For Eclipse Integrate QT Ecplise plugin and extend for Yocto Project 2 Review jzhang Enhancement
Bitbake commander Leverage and extend some features of bitbake commander into Yocto plug-in 2 Review jzhang Enhancement
Poky Image Creator Interaction Allow user to interact with poky image creator app through Eclipse IDE 2 Review jzhang Enhancement
push TCF/RSE patches upstream work with community to finish up our TCF terminal service, TCF/RSE

integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865

2 Review jzhang Enhancement
oprofileUI Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) 2 Review lianhao.lu Bug #382

Bug #493

IDE Project templates Templates for various project types (Clutter GUI, Gtk+ GUI, Qt GUI, daemon with d-bus, etc) to help developers get started quickly 2 Review josh Enhancement
SDK user workshop Have some developers sit down and use our tools to develop demo software for Yocto. 2 Review josh Enhancement
Profiling/Trace GUI's We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! 2 Review josh Enhancement

Documentation Features

Feature Name Description Priority Status Source Comments / Bugzilla Links
Self Documentation of image contents I'd like to see the -doc packages Poky builds being combined into some

kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a "bitbake world" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too.

2 Review rpurdie enhancement
Package report system Our intern has setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably 2 Review ktian1 enhancement


Feature Name Description Priority Status Source Comments / Bugzilla Links
Testing Framework Add a framework for doing automated testing in the project 2 Review davest project commitment
Runtime testing Runtime testing of images as part of the autobuilder 2 Review rpurdie project commitment
more SDK builds on autobuilder enable more SDK related tests on autobuilder such as meta-ide-support, etc. 2 Review ktian1 project commitment
more people should try using SDK this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it 2 Review ktian1 project commitment
Unit Testing Framework Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target 2 Review sgw project commitment
Personal tools