Various misc changes to convert bitbake to python3 which don't warrant
separation into separate commits.
(Bitbake rev: d0f904d407f57998419bd9c305ce53e5eaa36b24)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3 can't cope with the previous approach we were using to pass
exceptions through the RPC. Avoid this by creating a formatted exception
on the sender side.
(Bitbake rev: d7db75020ed727677afbad07a90fb3eac0bf2c45)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the addition of function line number handling, the overhead of
the compile functions is no longer negligible. We tend to compile
the same pieces of code over and over again so wrapping a cache around
this is beneficial and removes the overhead of line numbered functions.
Life cycle of a cache using a global like this is in theory problematic
although in reality unlikely to be an issue. It can be dealt with
if/as/when we deal with the other global caches.
(Bitbake rev: 98d7002d1dca4b62042e1589fd5b9b3805d57f7a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If subprocess raises a CalledProcessError() error, e.g. from a call
like subprocess.check_call("false"), bitbake would try and pass the
object over IPC and fail, leading to an unusual error:
('__init__() takes at least 3 arguments (1 given)', <class 'subprocess.CalledProcessError'>, ())%
To avoid this, we turn the value into a string which prevents the
issues the IPC has trying to deal with the object (for the same reason
we deal with tracebacks here too).
[YOCTO #8752]
(Bitbake rev: 05695424b918fc81b16cbac70d79d8271a0b6045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you start and suspend a bitbake execution so the bitbake lock is held,
then try and run "bitbake -w '' X", you will see bitbake return an error exit
code but print no message about what happened at all.
The reason is that the -w option creates a "UI" which swallows the messages. The
code which handles this exit failure mode thinks a UI has printed the messages
and therefore doesn't do so.
This adds in an extra parameter to the UI registration code so that we
can figure out whether its a primary UI or not and base decisions on whether
to display information on that instead. This fixes the error shown above and
some bizarre failures on the Yocto Project Autobuilder.
[YOCTO #8239]
(Bitbake rev: d1d60a68c2de40c2984d5040d14251c1be121b0b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow any listeners for this event (such as buildhistory.bbclass in
OpenEmbedded) to find out if the build was interrupted rather than
completing normally. The value will be 0 if not interrupted, 1 if
interrupted waiting for remaining tasks to complete, or 2 if force
interrupted (stopping any running tasks immediately).
(Bitbake rev: df2b778efd2ecc48f6c5a3ed446f6459f2250035)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With python you should not assign a list as the default value of a
function parameter - because a list is mutable, the result will be that
the first time a value is passed it will actually modify the default.
Reference:
http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments
(Bitbake rev: 7859f7388f2e3f675d0e1527cfde18625f36f637)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Events can call each other recursively, e.g. an event handler can call
bb.note which in turn generates another event. If these loop, it
can lead to multiple deletions of 'd' from __builtins__ which
can fail since __builtins__ is global scope.
Add handling to only remove 'd' when we added it and it wasn't already
present.
(Bitbake rev: b45952650ce8f470f124df36185b79e0d3a1783a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To quote Chris Larson:
"""
e.data.getVar() gets a bit old in a large event handler, and it means a
simple handler has to be modified if switching between an event handler
(e.g. RecipeParsed) and anonymous python. I think it would make sense
to restore the 'd' convention here to align with python elsewhere.
It'd just be a convenience, d==e.data, to avoid the common pattern of
setting it at the top of the event handler.
"""
I couldn't find a way to inject 'd' via locals/globals due to the use
of a function parameter so this left __builtins__ as the only way
I could find to make this work.
[YOCTO #7668]
(Bitbake rev: 44ac81e5281fb62ad00e2f79a9d754118ea62526)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The metadata can potentially use such an event to clean up any
"unreachable" data, solving several problems we currently have
where obsolete data may continue to exist in the shared areas.
(Bitbake rev: c5e6f929f3d5eeb7954660dea62611c58b795ff8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you don't explicitly specify to use a global variable when doing an
assignment, you will be setting a local variable instead, which means
this function wasn't working at all. It explains some odd behaviour we
have seen in the layer index where event handlers were sometimes
bleeding into other contexts where they should not have been.
(Bitbake rev: ac45ea848901b0f6cd23087b662dde8ce9cd807e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using external tinfoil-based utilities, it is useful to be able to
turn off most of the event handlers; for example sstate_eventhandler
doesn't like being sent events for any recipe which has been skipped.
(Bitbake rev: 41236c28985a3b66b3737382a94e39dbf6480160)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(Bitbake rev: 587b144ee409d444494d8d7f2d1c53ede8f7c953)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch fixes a name collision on the event.data
in the MetadataEvent class. event.data is used in the
event system as a copy of "d" in certain situations,
and this collision triggered a bug leading to data loss.
[YOCTO #6332]
(Bitbake rev: 3f191b7cfe95aea4d4e96babf001d62d45dd3aaa)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the depths of time we were rather confused about naming. bb files
are recipes, the event to skip parsing them should be SkipRecipe,
not SkipPackage. This changes bitbake to use the better name but
leaves the other around for now. We can therefore start removing
references to it from the metadata.
(Bitbake rev: 98d9e6e0f514a7cb7da1d99bf4bd5602b89426d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need BBHandledException events to be passed through to the higher
layers, they don't need addition of any traceback since they've already
been reported to the user.
(Bitbake rev: f63b61f8997862439519f474cc09f3e05e95288c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If an event handler triggers a SkipPackage event, we really want that
event to be received and processed by the higher code levels. Currently
it was getting caught and ignored which was leading to recipes
being present when they clearly shouldn't have been.
In general this exception catching looks to be doing the wrong thing. It
was introduced in
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/bitbake/lib/bb/event.py?id=37cb4cc02b2e2b6c338c5943747e0a1ef15176b3
but we likely want exceptions to pass through to the higher layers.
This patch therefore removes that code.
(Bitbake rev: 79211b3434855942f9fad4a1db69ce7be911327c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sanity tests are currently a pain as its hard to control when they run. This results
in issues where for example the bitbake -e output is not useful as the sanity tests
prevent it from executing. The sanity tests should run later than the base configuration.
This patch changes the sanity tests to always be event triggered with the option of
returning either events on the status, or raising errors. A new cooker feature is used
to change the behaviour depending on the controlling UI.
This does need a change to sanity.bbclass in the OE metadata but its worth the pain
for the increased flexibility and control this offers UIs and the improvement to the
user experience.
(Bitbake rev: 32e171bcc92c6e27fefee971e8714ddf8e1a8ac1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding the generic bb.event.MetadataEvent that is
targeted specifically at metadata usage. This is
needed in order to let the metadata code send and receive
events during asynchrous execution without having
to define each event specifically in Bitbake.
Metadata code should subscribe to and fire the MetadataEvent
in order to communicate asynchronously, and identify
the object using event.type field, and parse the
data in the event.data field.
Knotty UI will ignore these event by default.
This deprecates RequestPackageInfo/PackageInfo, and that
event pair will be removed in the future.
(Bitbake rev: ae1ea51aaab73e010d1c3db39df058bebebc11dd)
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default for the mask will be * (all the handlers)
(Bitbake rev: 4c95e5f46cf2a656100bbf5a0e5a09d506abf9b9)
Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add functionality to allow UIs to update and change the types of events they
recieve. To do this we need to add a new command and also need to be able
to obtain the current event hander ID. In the case of xmlrpc, this is
straightforward, in the case of the process server we need to save the result
in a multiprocessing.Value() so we can retrive it. An excplit command
was added to the server API to facilitate this.
The same function can also be used to mask or unmask specific log messages,
allowing the UI to optionally differ from the standard set of message
filtering.
Based upon work by Cristiana Voicu <cristiana.voicu@intel.com>
(Bitbake rev: ba5a6c88785d9889d4172ec79937ac2a5555327e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently one of the bigger bottlenecks in bitbake is passing all the
log messages over IPC to the UI. This is worthwhile if the UI is going
to use them, pointless otherwise. The memory resident bitbake suffers
from this performance issue particularly badly.
This patch filters the log events on the server side with the global
log levels and hence reduces the traffic. This speeds up parsing
(18.5s down to 17s) and bitbake general command overhead is reduced
(7.3s for a NOP to 6.2s).
What isn't added here is general event filtering or the ability to
change the log levels once set. Provision is made for adding this
in a follow up patch though.
(Bitbake rev: 1bf0e88f57ba0bca62532e81d0d62cf88e2abcbb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Assuming there is no known reason why an item is not provided, show
close matches on the assumption that it might have been a typo or
other mistake.
(Bitbake rev: ed81b0856b4a3892b53d39871eaaa6273390ea75)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a flag to event handlers which lists the events a given handler wishes to
process. By default event handlers recieve all events but this means
we can stop running code in many cases if we know it doesn't want the event.
This is part of the fix for YOCTO #3812, but implements filtering only
for class event handlers; the other part (events filter for UIs) will be
the subject of a different patch.
(Bitbake rev: 074003a4e7530a72863b9c685fc5c31b0f08c039)
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a pretty fundamental change to the way bitbake operates. It
splits out the task execution part of runqueue into a completely
separately exec'd process called bitbake-worker.
This means that the separate process has to build its own datastore and
that configuration needs to be passed from the cooker over to the
bitbake worker process.
Known issues:
* Hob is broken with this patch since it writes to the configuration
and that configuration isn't preserved in bitbake-worker.
* We create a worker for setscene, then a new worker for the main task
execution. This is wasteful but shouldn't be hard to fix.
* We probably send too much data over to bitbake-worker, need to
see if we can streamline it.
These are issues which will be followed up in subsequent patches.
This patch sets the groundwork for the removal of the double bitbake
execution for psuedo which will be in a follow on patch.
(Bitbake rev: b2e26f1db28d74f2dd9df8ab4ed3b472503b9a5c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to the execution context changes, establish better lifetime
management API of the class event handlers.
(Bitbake rev: 54e35a6cceead9521f8b1dacd48e55064e85c8bd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These have long since been deprecated, lets remove them.
(Bitbake rev: 3dc83bbb1bf387bb7ecea2e17f0f72cfccecba92)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch allows the user to check the network connectivity in
the "Proxy" page ("Settings" dialog) by adding a button which provides
this functionality. It also disables retrigerring sanity checks if the
proxy values are changed, since now the proxy checks are explicit.
Note that this patch depends on a patch in oe-core
("sanity.bbclass: trigger network tests explicitly"). It will
not work properly if the patch in oe-core is not merged.
[YOCTO #3026]
(Bitbake rev: cb1354d29c0be27aee57b9783c724457ef6725fb)
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds a sanity check progress screen to hob. The screen
is displayed when Hob executes the sanity check procedure. The screen
is displayed for at least 5 seconds. If a network error is detected,
a special dialog is displayed which lets the user open the proxy
configuration page directly.
Note that currently bitbake triggers the network tests only when
the value of its TMPDIR variable changes, which happens fairly rare
on my system. This is the subject of another bug (#3026).
Version 2 of the patch splits the changes in two parts (sanity.bbclass
belongs to oe-core).
[YOCTO #3025]
(Bitbake rev: b48f1351271cc066ffe919db112b14834a6d8f8f)
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The LogExecTTY even is intended to provide the ability to spawn a task
on a the controlling tty, if a tty is availble. When a controlling
tty is not availble the previous behavior is preserved where a warning
is issued about the action an end user must execute.
All the available UI's were tested against the new event type.
This feature is primarily intended for hooking up a screen client
session automatically on the controlling tty to allow for a more
streamlined end user experience when using a pure command line driven
environment. The changes that send the LogExecTTY event are in the
oe-core side.
(Bitbake rev: cffe80d82a46aaf52ff4a7b6409435754043553f)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This ensures that our event handlers get run in registration order, making the
behavior more deterministic. I pulled in the python2.7 OrderedDict to avoid
essentially reimplementing a version of it ourselves, figuring we can drop it
when we bump our required python version next.
(Bitbake rev: 44aa0b0537d3fbd1272015e7677948f84d8c0607)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If BitBake exits before a UI handler (server) has been registered, we
print the event queue; if there are any errors or other non-debug
messages just print these and suppress the rest of the message queue.
This improves the output when sanity check failures occur with OE-Core
by avoiding printing a long stream of uninformative debug messages.
(Bitbake rev: 8668a94cb1841798636b68fe123400d6b81f6574)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This improves the stacktraces dumped by bitbake when for example anonymous
python functions fail.
Also default to passing code strings to better_exec to match the behaviour of
simple_exec to aid the transition.
(Bitbake rev: 7e8205929ae953731a6854ea80b197847cff5771)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Part of [Yocto #2168]
Add a event DiskFull to descript the termination by disk monitor.
Update check() to fire the event DiskFull when terminates the build.
This could help UIs to deal this scenario and show more information to
end user.
(Bitbake rev: 0a0fca3d94a1db6458ae21501a66461a334410ed)
Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to show a friendlier error message that does not bury the
actual sanity error in our typical preamble about disabling sanity
checks, use a separate event to indicate that sanity checks failed.
This change is intended to work together with the related change to
sanity.bbclass in OE-Core.
Fixes [YOCTO #2336].
(Bitbake rev: 24b631acdaa143a4de39c6e1328849660c66f219)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The changes include:
- Clean some events in event.py
- Fire essential events for Hob2 to handle with more information.
- knotty changes
(Bitbake rev: 9ede881620c501574f014e600cea6947ea908ac2)
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RequestPackageInfo is triggered by GUI client to request the available
package information.
PackageInfo event is to pass package information back to GUI.
(Bitbake rev: 9020c2d4476766f63ff7e024bbd99043d06feefc)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no direct use of command in cooker.py, and it is using
bb.command instead. Remove command in the import list.
This fixes a problem of embedded import between command.py and
cooker.py.
(Bitbake rev: c353316b2efcc7a893d6b4aa9a9647d51a6f69e3)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"Nothing PROVIDES" errors often come up when a recipe has been skipped
for some reason, and therefore it is useful to print out that reason
information when showing the error so that the user understands why the
error has occurred.
Given that we already feed the reason information into the skiplist for
various situations (COMMERCIAL_LICENSE, COMPATIBLE_MACHINE etc.) this
should now output a useful error message for skipped recipes.
Fixes [YOCTO #846], [YOCTO #1127]
(Bitbake rev: 6765218430e31c165888f26fbc75023c89a6eab2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was displaying the log messages in LIFO order, which isn't what we
expect to see. Thankfully this only occurred during an early abort (e.g.
config file parsing error), but those are the cases where it's very
important to see accurate messages, to diagnose.
(Bitbake rev: b838e0f3a1b481c295f66f5c9f561fa4d51de673)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This command can be used to search each BBPATH for files in the passed
directory which have a filename matching the supplied pattern.
This is implemented for use from the GUI (to determine the available
PACKAGE_CLASSES) but has been written so as to be generically useful and
reusable.
(Bitbake rev: 2a599812a57cb0b964880a6a2b7548423497ea92)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This takes the name of a .conf file and returns the full path to it
(Bitbake rev: 22c8600b885faf841795b872d82f68dfb644a26e)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the implications is we need to register the event handlers before
executing the anonymous python functions. I can't find any issue with making
that change in any existing metadata use cases.
(Bitbake rev: a981df3cc9bf410d24f39919959952bdc6c76d03)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we use bb.exceptions to pass pickleable traceback entries to the UI, and
the UI is free to do whatever it wants to do with this information. By
default, the log formatter for the UIs formats it with bb.exceptions. This
also means that all exceptions should now show 3 lines of context and limit to
5 entries.
(Bitbake rev: ee48d628ee038bd72e1cd94aa75f5ccbacbcee4c)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only the xmlrpc server needs pickled events. Use the function names
to signify this requirement.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means that anyone firing an event can get a systemexit and result in
their process exiting, which isn't ideal, but behaves the way it used to (in
particular, ensures that a sanity check failure will halt the build). This
should be revisited in the future.
(Bitbake rev: d6a0ffdd583be3df734171d7e91d334f798a79ce)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie
Christopher Larson
Paul Eggleton
Robert P. J. Day
Alexandru DAMIAN
Cristiana Voicu
Bogdan Marinescu
Jason Wessel
Kang Kai
Dongxiao Xu
Shane Wang
Joshua Lock