Yocto Features

Yocto Project 1.0 Feature Planning

This page captures the planned / requested features for the Yocto Project 1.0 release across all supported architectures and platforms (Atom).

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

Legend

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

Validation

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