Yocto Project - User contributions [en]

Member Technical Contacts

2021-04-06T16:06:52Z

Denix:

This page tracks the official technical contributors to the YP core from each of the Yocto Project's member organizations. Note that many organizations provide more resources than just one, particularly in terms of hardware or specific feature support, which is why the Yocto Project is a de facto standard for building Linux for embedded systems.

Platinum Members
* Arm: Ross Burton <ross.burton@arm.com>, Jon Mason <jon.mason@arm.com>
* Amazon: Richard Elberger <elberger@amazon.com>
* Cisco: Taras Kondratiuk <takondra@cisco.com>
* Comcast: Raj, Khem <Khem_Raj@comcast.com>
* Facebook: DJ (Dharmesh Jani) <janidb@fb.com>
* Intel: apoorv sangal <apoorvsangal@gmail.com>
* Microsoft: Paul Eggleton <paul.eggleton@microsoft.com>
* Wind River: Robert Yang <liezhi.yang@windriver.com>; Saul Wold <Saul.Wold@windriver.com>
* Xilinx: Mark Hatle <mhatle@xilinx.com>

Gold Members
* AGL: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
* Mentor Graphics: Chris Larson <chris_larson@mentor.com>
* Renesas: Mr. Takamitsu Honda <takamitsu.honda.pv@renesas.com>
* Texas Instruments: Praneeth Bajjuri <praneeth@ti.com>

Silver Members
* AMD: Wade Farnsworth <wade_farnsworth@mentor.com>
* Dell: Michael Brown <michael.e.brown@dell.com>
* Enea: Catalin Doras <catalin.doras@enea.com>
* Founderiesio: Ricardo Salveti <ricardo@foundries.io>
* LG: Minjae Kim <nate.kim@lge.com>
* Linaro: Nicolas Dechesne <nicolas.dechesne@linaro.org>
* Lineo Solutions: Masahiro Miyake <miya@lineo.co.jp>
* MontaVista: Armin Kuster <akuster@mvista.com>
* NXP: Lauren Post <lauren.post@nxp.com>
* Savoir-faire Linux: Sébastien Le Stum <sebastien.le-stum@savoirfairelinux.com>
* ST: Christophe Priouzeau <christophe.priouzeau@st.com>

Technical Partners
* OpenEmbedded: Philip Balister <philip@balister.org>

Future Directions

2020-12-15T17:45:14Z

Denix:

= Potential Future Project Directions =

The Yocto Project TSC has been giving thought to the “big picture” areas of the project which could potentially be developed in the future. These are listed below, where possible the TSC has tried to indicate what these topics are, why they are important, their current status, developments that are happening and what else we believe might need to be done. If there are other areas which anyone believes should be on this list, please raise it with the TSC. The list is in approximate priority order from the TSC’s perspective although in reality, resource constraints can impact ability to make progress on any topic area, or allow it to happen if it is sponsored by a contributor.

In generating this list the TSC is considering many factors and are considering this from a project wide perspective. We realise individual contributors and members have different priorities and the priority will also be heavily influenced by where resources are available to help, be it from the community or from members. Assigning a priority is hard as the TSC can have limited impact on many topics as it has no resources to assign.

== LTS ==
LTS proposal already published and acted upon, see [[LTS]].

== Security ==

There are two areas the project has been asked to define or provide:
;PSiRT
: This is a group of individuals who have the task of monitoring, responding to and logging vulnerabilities for the Project.
: By using various input sources, issues are evaluated and the appropriate actions are taken.
: A scoring matrix will need to be defined
: A set of tools will need to be defined to assist in this effort
;Vulnerability mitigation
: This is the process of removing a security vulnerability either by a patch, configuration change or workaround.

There is some research and proof of concept work occurring with some tools but its struggling due to lack of people/resources.

== Layer setup/configuration ==
Currently each user of the project is responsible for setting up layers and stub configuration files themselves. This could include downloading bitbake and metadata layers and then generating configuration for the user, then later also support updating some of the components as appropriate.

There are multiple approaches out there (combo-layer, git submodules, repo, WindRiver setuptool, YP autobuilder, KAS tool from Siemens. other shell/python scripts). Each has pros/cons. This fragmented approach isn’t good for the project, it would be better if we had a unified approach. One tool probably won’t fit all but there are too many right now. This task would be to investigate the area and come up with a proposal/path to improving things.

== YP Compatibility ==

The current YP compatibility programme has stalled. From a technical perspective there are minor gremlins but we believe it's the right direction.

The issues have been:
#problems with the webform
#nobody to resolve open bugs with the process
#process improvements needed (ensure the tools are run consistently with reproducible results)
#current testing process is too manual
#not being marketed enough
In the view of the TSC, the project is currently missing out on opportunities here, both to attract new members and to improve the quality of the layers/metadata. It is suffering from lacking someone to own and drive the process.

== Developer Tools and Processes ==

Currently we have devtool, eSDK and unmaintained eclipse integration. Need a plan to improve eSDK, have a build which can migrate between “sdk” and “full” build modes. Also need plans for new IDE integration, particularly Microsoft Visual Studio Code which appears to be the modern IDE to target.
There is a long standing bug for a “lock/unlock” bitbake command to move sections of recipes between the two modes which would be one stepping stone to completing this work and improving eSDK usability. Tools to show the locked status of recipes would also help, as would better tools to debug signature differences.

Secondly, adding better layer setup/configuration tooling would remove the need to handle this in eSDK, removing a fragile part of the current codebase [see separate item above].

== Usability ==

The TSC discussed usability which is a wide-ranging topic. We believe that several of the specific topic areas proposed previously actually work towards the goal of improving project usability. For example, the patch submission process would benefit new developers who are more familiar with a “github” style patch submission process. Another significant change would be the layer setup process which would help with another subsection of usability. There is also a community aspect to usability through different mediums such as stack overflow, twitch, OEDEM/OEDAM, devdays and all the other programmes the project participates in or runs.

A critical area in the TSC’s opinion is the enhancement and redevelopment of eSDK and tools like devtool (and creation of new tools alongside it) as the original idea was good but the implementation has issues which nobody is currently working on. This area has not been scoped out by the TSC as a specific proposal as yet but is a well-known area of the project that needs development.

Usability has so many different focuses that different people will prioritise different components of this and have different ideas. It also depends on the skills of any resource available as to the pace any given area can move forward.

== QA automation ==
It has become very clear that automated testing is our only realistic way forward for the project. We’ve made massive improvements to the infrastructure both in hardware (through a refresh) and in software (yocto-autobuilder2/yocto-autobuilder-helper/resulttool).

We need to:
#raise awareness of what automation capability we already have
#have more people looking at the test results
#Work in improving test results (many ptests failures currently)
#Improve release test comparison so its reliable/useful
#encourage more people to submit test results against a release
#finish new testing documentation manual

Example Test Report:
:https://autobuilder.yocto.io/pub/non-release/20190909-13/testresults/testresult-report.txt

Armin will use meta-security as an example? Become a talk?

== Code Submission process ==
The project uses what is considered to be a fairly ‘old school’ approach to code submissions. The older project members are comfortable with this and it has advantages (like peer review). There are more modern approaches which may encourage contributions from a wider audience.

The OE community is trying an experiment with gitlab with some specific layers where the maintainer is willing to experiment to understand what works well and what doesn’t, we’re likely to await the results of that to decide how to proceed:

Using GitLab for OE/Yocto layers

== Binary Distro ==
There are a subset of users of the project who need “binary package feeds” similar to a conventional Linux distro. They don’t want users to have to build things themselves, simply download and use them. Users look at Debian/Ubuntu and other distros and don’t understand why YP doesn’t do this. The difference between a source distro and a binary distro is lost on them.

The challenges:

#finding a configuration which all these users could agree on to have a feed which would work for multiple consumers
#deciding which binaries should be supported (on which architectures and target optimizations)
#maintaining a potentially large set of such binaries
#testing upgrade paths between releases

There is a large resource commitment needed, even if much automation can be made to try and make this possible. If the project itself hosting a binary distro isn’t viable, having tools and adding testing for the processes needed to do this would be extremely valuable.

== Software Update ==

Currently the only official update mechanism YP supports is through conventional package management (rpm/ipk/deb). There are other better alternatives for some situations such as ‘A’/’B’ updaters or update mechanisms with less granularity than packages. Mender and Resin have commercial solutions, there is also swupdate and OSTree in particular. These provide whole system updates in one, or larger groupings of updates than just packages.

Open questions are whether any of this should be core technology and whether anything in core should change to better support this.

At the very least we need to document the options users have for software update.

What the project likely needs to do in this space is provide infrastructure/prototypes and automated tests of the building blocks and processes people would need to do any of the above.

== Modern Programming Language Runtimes ==

We see patterns where there are new language runtimes such as rust, go, nodejs and to some extent, perl and python where there are large numbers of dependencies which don’t conform to our ideas of larger units of software with specific releases/versions that are well defined by recipes. We need to consider strategies at the architecture level to work better with these.

== AI/ML ==

We also should consider strategies at the architecture level to cover and unify AI/ML usage in/by the project.

== Other future topics ==

Other areas which need development:
#Support for multiple toolchains (clang or arch specific e.g. intel or arm compilers) as not all recipes build with standard gcc any longer

Member Technical Contacts

2016-11-22T22:35:36Z

Denix:

This page tracks the official technical contributors to the YP core from each of the Yocto Project's member organizations. Note that many organizations provide more resources than just one, particularly in terms of hardware or specific feature support, which is why the Yocto Project is a de facto standard for building Linux for embedded systems.

Gold Members

* Intel: Ross Burton <ross.burton@intel.com>
* Wind River: Robert Yang <liezhi.yang@windriver.com>; Mark Hatle <mark.hatle@windriver.com>; Bruce Ashfield <bruce.ashfield@windriver.com>
* Texas Instruments: Denys Dmytriyenko <denys@ti.com>
* Juniper Networks: Name <email>
* Xilinx: Name <email>
* Mentor Graphics: Chris Larson <chris_larson@mentor.com>
* OpenEmbedded: Name <email>
* Long Term Support Initiative: Name <email>

Silver Members

* Renesas: Mr. Takamitsu Honda <takamitsu.honda.pv@renesas.com>
* Linaro: Koen Kooi <koen.kooi@linaro.org>; Nicolas Dechesne <nicolas.dechesne@linaro.org>; Fathi Boudra <fathi.boudra@linaro.org>
* MontaVista: Armin Kuster <akuster@mvista.com>
* Dell: Name <email>
* OS Systems: Fabio Berton <fabio.berton@ossystems.com.br>; Otavio Salvador <otavio@ossystems.com.br>
* Broadcom: Name <email>
* Enea: Name <email>
* AMD: Name <email>
* Timesys: Name <email>
* LG: Name <email>
* NXP: Name <email>
* Huawei: Name <email>

BSP Summit

2012-04-04T17:30:04Z

Denix: /* Agenda */

The Yocto Project BSP Summit will be held April 2, 2012 at Mentor Graphics headquarters in Fremont, CA. This summit, which happens the day before the Linux Collaboration Summit in San Francisco, will focus on the creation of BSPs based on OpenEmbedded Core and usable by the Yocto Project. In addition to presentations, the summit will include working sessions to provide developers with the opportunity to refine the common definition of BSP layers and work collaboratively on their own BSP layers. To that end, developers are encouraged to bring development boards to work on during the summit. To continue the momentum for those also attending the Collaboration Summit, the Yocto Project will host an all-day working meeting give to work on their BSPs with community members.

NOTE - Although this event is timed to coincide with the [https://events.linuxfoundation.org/events/collaboration-summit Collaboration Summit] in San Francisco, please remember that the Collaboration Summit is a completely separate event. If you want to attend Collaboration Summit, you need to [https://events.linuxfoundation.org/events/collaboration-summit/request-an-invitation request an invitation from Linux Foundation].

= Agenda =

08:00 - 09:00 -- Social/continental breakfast provided by Mentor Graphics 
09:00 - 09:15 -- Welcome and introduction (Sean Hudson, Mentor Graphics) 
09:15 - 10:15 -- Current state of Yocto Project BSP definition (Tom Zanussi, Intel) 
10:15 - 10:30 -- Break 
10:30 - 11:30 -- Working with meta-ti (Denys Dmitriyenko, TI) [[File:meta-ti.pdf]]
 
11:30 - 12:30 -- Lunch provided by Mentor Graphics & hardware setup 
12:30 - 13:00 -- BSP strategy (Bruce Ashfield, Wind River) 
13:00 - 14:30 -- Yocto Project BSP open discussion (moderator: Sean Hudson) 
14:30 - 17:00 -- Working sessions 
17:00 - 18:30 -- Beer & pizza provided by Mentor Graphics

= Live Video/Audio Conference Information =
In order to allow for additional participation from the community at the BSP Summit,
Mentor Graphics will be providing a live video conference, a WebEx session, and recording
the stream for later viewing. Details can be found below. Please feel free to share
this information with colleagues that are unable to attend in person.

Live video conference details
----
Conference ID: 101

Video participants will need to call into the Video Conference Bridge using one of the methods below.
Once connected to our Video Conference Bridge, please enter the Conference ID followed by the # sign.
IP Address: 192.94.38.249
Video Address (H.323 or SIP): video@mentor.com

NOTES:
The video conference will not connect until the call is active. However, it will become live ~15 minutes early.
A video conference setup will be required to connect. A free client can be found at [https://www.ekiga.net ekiga.net]

Webex information:
Meeting Number: 758 201 571
Meeting Password: Yocto

= Venue =

The event will take place 8am-5pm at Mentor Graphics headquarters in Fremont:

46871 Bayside Parkway 
Fremont, CA 94538 
Tel: (510) 354.7400

= Local Hotels =

Mentor has recommended the following hotels:

'''Marriott''' (Nice, 1 Mile away, $134/night) 46100 Landing Parkway, Fremont, CA 94538 (510) 413-3700 ‎

'''Courtyard Fremont Silicon Valley''' (Budget, .5 Miles, $84/night breakfast included) 
47000 Lakeview Boulevard, Fremont, CA 94538 
(510) 656-1800 (510) 656-2441 (Fax) ‎

If you plan to take public transportation, there is a BART terminal in Fremont about 15 minutes away from the Mentor Graphics office. The nearest CalTrain station is either Santa Clara or downtown San Jose, both about 20 miles away, but you can transfer to Santa Clara Light Rail blue line up to the Great Mall station in Milpitas, which is only about 8 minutes from Mentor.

= Carpooling =

For those who have an extra seat in their car as well as those who wish to ride with others, please [mailto:jeffrey.osier-mixon@intel.com let me know] and I will try to match up the latter with the former.

File:Meta-ti.pdf

2012-04-04T17:28:25Z

Denix: