Yocto 1.1 Features

Potential Yocto Project 1.1 Features

Yocto Project 1.1 - Target release = October 2011

Yocto Project 1.1 Themes

The topics below are the themes that some members of the team have started brainstorming for Yocto Project 2011.10. These will grow and change with community input.

Yocto Project 1.1 Objectives

The objectives of the Yocto 1.1 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

Yocto Project 1.1 Theme List

The Yocto Project 1.1 Themes towards the Objectives listed above are:

• Multilibs & OE-core config - This work, which began in Yocto Project 1.0, needs to be completed.
• Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
• Enable users to easily and seamlessly build Yocto images - This refers to the effort to complete and integrate the Image Creator work started in 1.0.
• Build performance – Get to the goal of 1 hour build time on a developer machine.
• Upstreaming – Submit patches to upstream projects in order to reduce the large number of patches which are currently part of Yocto Project.

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

Sample Table

This is a sample table to show how to submit features.

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Placeholder feature name	Placeholder description of the feature	1, 2, or 3	Review	name	Comment

Architecture

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Layer Tooling	This includes the architectural work plus implementing the changes.	1	Review	Architect	M2; Owner = Richard
OE-Core	Restructuring, renaming, rebranding	1	Review	RP Notes	M1; Owner = Richard

Core/Bitbake

This section contains features for the Poky/Bitbake infastructure.

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Error handling in bitbake	desc	1	Review	RP Notes	M2; Owner = Saul (ScottG)
crazygit fetcher	TI issues with fetch2 - per LCS - should this be a P1?	2	Review	RP Notes	M1; Owner = Saul (Ke) Timescale: 2-3 days
multi-lib	multi-lib support for 32-bit & 64-bit and capable of being installed at the same time	1	Review	from 1.0	M1; Owner = Richard (Qing)
Image Creator	finish the Image Creator to add features pushed out from 1.0	1	Review	from 1.0	M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
Web-based Image Creator	Create a web-based interface that does what the Image Creator does.	TBD	Review	LCS	not in schedule
Recipe-specific sysroot		3	Review	from 1.0	M2; Owner = Saul (Dongxiao)
Handle old versions in WORKDIR		3	Review	from 1.0	Not scheduled at this time
Package config option enhancement	need to plan and then implement	2	Review	from 1.0	Owner: RP for plan, Saul implementation
Clean up warning messages	A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings	2	Review	davest and RP	M2; Owner: Saul
Monitor disk availability	Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem	2	Review	RP and Robert	M2; Owner: WR Distro Team
Publish Shared State	Publish the shared state information.	TBD	Review	LCS	not in schedule
Ease of package repository publication	Make it very easy for your team lead to publish a package repository for the rest of the team to use (this needs to be clearly documented)	TBD	Review	LCS	not in schedule
Executable images	Create images that are executable - for example a pre-installed Ubuntu image with YP installed	TBD	Review	LCS	not in schedule
Self-hosting image	Create customizable chroot; Build an image that would be self-hosting	TBD	Review	LCS	not in schedule
Yocto OOPS-type messages	add the equivalent of kernel OOPS to Yocto	TBD	Review	LCS	not in schedule
Reduced depth revision history	Decrease the depth of the revision history	TBD	Review	LCS	not in schedule
Ability to archive work dir	Add the ability to archive the work directory to handle the GPL compliance issue.	TBD	Review	LCS	not in schedule
Selective pull back archive	Selectively turn on the ability to pull back a revision tag archive	TBD	Review	LCS	not in schedule
Address rebase issue	Address the issue that can occur when the upstream is rebasing and there is lost information in the local git.	TBD	Review	LCS	not in schedule

QA Items

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
SDK support in sanity test framework	This task includes enabling unfs and toolchain testing in sanity test framework, enabling toolchain testing on PRC autobuilder	1	Accept	QA	M1; April 29th; Owner = Jiajun/Meilei
Open Source Test Cases	Perform technical, legal, and QA steps necessary to move test cases into open source.	3	Review	QA	may have no resource to do this task;Owner = Jiajun
Test framework	this is a test framework that we can include in the distribution	3	Review	RP Notes	may have no resource to do this task;Is it the TI’s test framework we discussed before? Owner = Jiajun
Be prepared for Distro upgrades	Our release is right around the time of the 6monthly distro release dates, we should accommodate for this in our testing plan	2	Review	Joshua	M1, M2, M3, check latest distribution 1 week before milestone completes and test them in milestone testing; Should we include more Distributions, besides fedora, ubuntu and opensuse? Owner = Jiajun
Test Plan	Create an overall Test Plan for 1.1 and post on Wiki	1	Accept	Jiajun	M1; May 6th; Owner = Jiajun
Test Execution Plan	Create a Test Execution Plan for the milestone and send to developers	1	Accept	Jiajun	M1, M2, M3, 1 week before milestone completes; Owner = Jiajun

Meta-data

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Upstream our patches	We'll add this as a task in a milestone to give people time to do	1	Review	Meta-data	M2; Owner = Saul
3G	We have an ofono recipe but need some integration work doing	2	Review	Meta-data	M3; Owner: Saul (Dongxiao)
btrfs		2	Review	Meta-data	M2; Owner: Saul (Nitin)
Other components?	Saul will investigate other components.	2	Review	Meta-data	Owner: Saul
Replacement for video/audio players currently in Yocto	Codec…	3	Review	Meta-data	Not scheduled at this time
Investigate New UI	For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?	3	Review	Meta-data	Not scheduled at this time
Qemugl upstreaming	Opengl ES Support	3	Review	Meta-data	Not scheduled at this time
Sync qemugl with MeeGo		2	Review	Meta-data	M1?; Owner: Saul (Edwin)
Package reporting system enhancement		2	Review	Meta-data	M1; Owner: Saul (Lei)
pam patch integration	add PAM patches throughout the system switchable via the PAM feature (Mark H)	2	Review	Meta-data	Owner: WR Distro Team?
selinux patch integration	add SE Linux patches in a similar way to PAM	3	Review	Meta-data	Not scheduled at this time
Finish LSB "distribution" work	Merge patches which are pushed during ycoto 1.0. Add packages(qt3,xdg-* ...) LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.	2	Review	Meta-data	M1; Owner: WR Distro Team
OE Comparison	Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.	1	Review	Meta-data	M1; Owner = Mark
Framework to support multiple library versions co-existing	similar to recipe specific sysroot; needs documentation	2	Review	Team	M3?: Owner: Saul (Dongxiao?)
Embedded java environment or even JDK support		3	Review	Team	Not scheduled at this time
Automatically generate package repos	automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION	2	Review	Team	M1; Owner: Saul (Dexuan)
MeeGo GPLv2 Sync	compare with Yocto, sync any patches	2	Review	RP Notes	M2; Owner: Saul (Ke)
Incompatible License		2	Review	Paul	M3; Owner: Saul
End of package revision	replace with a network service	2	Review	RP Notes	Owner = Jessica
Target module build	Allow for building kernel modules on the target device	2	Review	RP Notes	Owner = Darren
Live images	make live images their own image type	2	Review	RP Notes	Owner = Saul
multiple update-alternatives	fixed - team thinks it's fixed	3	Review	RP Notes	Owner: Saul
init scripts	provide an image/recipe skeleton as a canonical example	3	Review	RP Notes	M1; Owner: WR Distro Team
running post installs at rootfs gen time		2	Review	RP Notes	M2; Owner: Saul (Dexuan)
remove gnome-vfs		3	Review	RP Notes	M2; Owner: Saul (Edwin)
gtk+ sato filechooser patch		3	Review	RP Notes	Not scheduled at this time
sato refresh		3	Review	RP Notes	Not scheduled at this time
adding eglibc config control	this goes with the package config options	1.5	Review	RP Notes	M2; Owner = Mark
Sanity checks on per recipe basis		2	Review	RP Notes Bug#405	M3; Owner: Saul (ScottG)
x32	layer to support toolchain, libc, and kernel	2	Review	RP Notes	M2; Owner: Saul (Nitin)
User Creation at preinstall		1	Review	RP Notes	M1; Owner = Mark (ScottG)
Directory Ownership		1.5	Review	RP Notes	M2; Owner = Mark (w/Qing)
Optimise Configure		2	Review	RP Notes	Performance idea, Owner: Saul
Ability to build SRPM		3	Review	RP Notes	Owner: Jeff Polk/Mark
Check SRCREV in recipe files	should work, may need dev	2	Review	RP Notes	M2; Owner: RP/Ke
Add Directfb（license LGPL） function	Directfb is more appropriate embedded device than other graphic software	3	Reject	Meta-data	Directfb has already been done

BSPs

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Support for AVX as in kernel 2.6.30. - Already in 1.0	Any toolchain support needed?	1	Review	Jay	M1; Owner = Nitin
Optimize support for Intel hardware features	We need to understand and track each important Intel hardware feature and how it should be optimally supported in the Intel BSPS. Items that immediately come to mind are power, video, and performance counter settings, etc.	1	Review	Tom	Owner: Tom/Darren
Fish River Island/Fish River Island II BSP(s)	The base Fish River Island BSP exists already, we now need to add support for the extra devices, and add support for changes introduced by Fish River Island II	2	Review	Tom	Owner: Tom
Support ECG (ongoing)	ECG is ramping up with Yocto BSPs and likely will require significant amounts of time and help. Also, since we're trading their BSP work for our help in upstreaming patches, we're also likely to have to spend a significant amount of time with upstream-related tasks too.	1	Review	Tom	Owner: Tom
Additional config options	The following configurations need to be enabled to support DPDK: Glibc >= 2.7 (for features related to cpuset) Kernel configuration HPET and HPET MMAP configuration options enabled All UIO kernel options enabled HUGETLBFS enabled PROC_PAGE_MONITOR enabled	1	Review	Rahul	Owner: Tom, M1
BSP update/intro	determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)	2	Accept	Bruce/Richard/team	Owner: Bruce, M2, 4th Sprint
upgrade EMGD	EMGD needs to be upgraded to the latest version (1.52)	2	Accept	Tom	Owner: Tom, M1
refactor BSPs to use topic branches	crownbay and fish river island BSP need to be changed to make use of the new eg20t/emgd/gma500 topic branches	2	Accept	Tom	Owner: Tom, M1

ADT

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
More test cases about toolchain in autobuilder		2	Review	ADT Team	Owner = Jessica
Eclipse-native tools interface	More integrated with upstream once there's integrated Linux tools that meets our need, e.g. lttng-remote	2	Review	ADT Team	Owner = Jessica
Indigo update	Update to the latest Eclipse release (Indigo)	2	Review	ADT Team	M2; Owner = Jessica
Changes for Image Creator	Eclipse changes pending Image Creator	1	Review	ADT Team	M2; Owner = Jessica
Secure login		2	Review	ADT Team	Owner = Jessica
Prebuit SDK integration	speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration	2	Deline	Adrian	This functionality looks to have been provided by sstate packages? Owner = Jessica
Systemtap integration	Make it easy and convenient for the user to write and execute Systemtap scripts from the IDE. http://www.eclipse.org/linuxtools/projectPages/systemtap/ might provide a good starting point and may be something we can contribute to. We may also need to contribute further up the chain to provide e.g. remote target capabilities.	2	Review	Tom	Owner = Jessica
'perf scripting' integration	Make it easy and convenient for the user to write and execute 'perf scripts' from the IDE. We should be able to leverage and build on the Systemtap integration for this.	2	Review	Tom	Owner = Jessica
Enhance the deploy part in remote debug	ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.	2	Review	Lianhao	Owner = Jessica

Documentation

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Package Documentation Audit	Make changes defined in the package documentation audit from Yocto 1.0	2	Review	from 1.0	Owner = Saul
Yocto Project Development Guide	This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).	1	Not Started	from scratch	M4 (final) Owner = ScottR
Various Demo Videos	The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.	2	Not Started	From ADT module and scratch	M2 Owner = ScottR
Open-source Newbie Information	This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.	2	Not Started	From scratch	M4 (final) Owner = ScottR
Tarball Doc process	Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.	3	Not Started	From scratch	M3 Owner = ScottR
OOB documentation	Create an out of box guide for giveaway systems built using Yocto.	1	Review	Julie	M? Owner = ScottR
Tracing/profiling HOWTOs	Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.	2	Review	Tom

Build

This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Autobuilder maintenance	Bring scripts into configuration or get git repo working for those that can't be brought in. (takes 2 days)	1	Review	Beth	M1; Owner = Beth
Meta targets	Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)	1	Review	Beth	M2; Owner = Beth
License tracking	Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)	1	Review	Beth	M1; Owner = Beth
License tracking	Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks)	1	Review	Beth	M2; Owner = Beth
Audotbuilder infrastructure	Bring up additional autobuilders and work with sysadmin to configure.	1	Review	Beth	M2; Owner = Beth
Overall Project	Host a retrospective to discuss what went well and what can be improved in Yocto 1.0. (questions on this?)	1	Review	Beth	M1; Owner = Beth
Release Scripts	Create Release Scripts that can be used for both a weekly release and for OCT 2011 release to be run by autobuilder (a week. testing on this may take longer)	1	Review	Beth	M3; Owner = Beth
Enhanced Performance	Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour	1	Review	from 1.0
Disk Space Reduction		2	Review	Team	Owner = TBD - WR distro team might be willing to own if they know what is required
Share gcc work directories		2	Review	Team	Owner = TBD - WR distro team might be willing to own if they know what is required
Patch Test System	Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added. (developer autobuilders? Fuzz builds?)	2	Review	Team
build statistics reporting	As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions		Review	eflanagan/Jay7/ka6sox
BSP builds	Autobuilder git fetcher improvements (3 days)	2	Review	from 1.0	M1; Owner = Beth
Implement Continuous Autobuilds	Build constantly instead of daily (need fuzz builds for this. once fuzz builds are implemented, this is trivial)	2	Review	from 1.0	M1; Owner = Beth

Performance and Usability

This section contains general Yocto performance as well as usability items.

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Fast boot time	2 second boot time target	1	Review	Team	M2; Owner = Darren
Build Yocto behind firewall	Darren will investigate site.conf and documentation	2	Review	Dave
Minimal Image unique	make minimal image smaller	3	Review	Team	M2; Owner: WR Distro Team
POSIX support	address POSIX failures found in 1.1	2	Review	Team

Kernel

This section contains items specific to the Yocto kernel.

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
BSP kernel config audit	Audit kernel configs for the various BSPS. Should not be limited to just kernel config options -- it should also include discussion of overall strategies for defining and managing base branches, feature topic branches, config features, etc, and should result in not only the current kernels being changed to match, but also BKMs being published somewhere, probably in the kernel manual.	1	Accept	Team	Owner = Bruce, M1, 4th Sprint
Kernel Tools	Figure out plan for kernel tools (are they merged into main repo or their own project?)	1	Accept	Bruce/Mark	Owner = Bruce, M1, 3rd Sprint
Kernel Tools	Implement plan for kernel tools	1	Accept	Bruce/Mark	Owner = Bruce, M1, 4th Sprint
Kernel Build	auto yoctization. allow the building of arbitrary repos and kernel versions via the yocto kernel meta data	1	Accept	Bruce	Owner = Bruce, M1, 2nd Sprint
Kernel Update	kernel dev/next repo created. feature merges (fs, boot, tiny, controllers, etc). reference tree merges (omap, davinci, etc)	1	Accept	Bruce	Owner = Bruce, M1, 3rd Sprint
Kernel Version	Confirm kernel version	1	Accept	Bruce	Owner = Bruce, 6 weeks before dev done
BSP config cleanup	BSP config cleanup/refactoring. Update to new kernel rev. Investigate Kconfig alignment	1	Accept	Bruce	Owner = Bruce, M2, 4th Sprint
inter-core comms	investigate/report/merge intercore communication methods (mcapi, dsplink,etc). extend as appropriate	2	Accept	Bruce	Owner = Bruce, M2, 1st Sprint
use cases	BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing	1	Accept	Bruce	Owner = Bruce, M3, 1st Sprint
Ongoing kernel maintenance	There should be a task spread out over the whole release, say 10% of one person's time (just a guess), for monitoring LKML and Linus' master branch, and/or relevant lists for patches relevant to the BSPs we maintain. We also need to figure out if Bruce needs help with the management of the base branches e.g. re-enabling features after kernel uprevs, moving feature tags forward, etc.	1	Review	Tom	Owner = Bruce, M2 4th Sprint
Tracing: perf trace scripting support	Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.	2	Review	from 1.0	Owner = Tom, M1 Sprint C
Tracing: Add Systemtap support for userspace tracing	Add utrace, etc	2	Review	Tom	Owner = Tom, M1 Sprint B
Tracing: Systemtap usability in Yocto	Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable 'out of the box' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar	2	Review	Tom	Owner = Tom
Tracing: tuna, oscilloscope recipes	catch up with Tom, likely to remove	3	Review	from 1.0	will be removed

Project-Wide Features

This section contains features for the entire project or for the project website or mailing lists.

Feature Name	Description	Priority	Status	Source	Comments / Bugzilla Links
Patchwork	is it worth the overhead, are there alternatives	3	Review	RP Notes
Alpha	Begin an alpha program after the stabilization period for M3.	1	Review	Team
Bugzilla to Wiki	Create a script which automatically populates and updates the Wiki based on changes in bugzilla.	?	Review	Darren