Yocto Features

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
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