Bug 10083

Summary:	RMC: Grab artifacts generated from other SW components at build time
Product:	[Build System, Metadata & Runtime] BSPs	Reporter:	Jianxun Zhang <jianxun.zhang>
Component:	bsps-meta-intel	Assignee:	Todor Minchev <todor.minchev>
Status:	RESOLVED OBSOLETE	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	bluelightning, sgw, tom.zanussi
Version:	2.2
Target Milestone:	Future
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Jianxun Zhang 2016-08-04 18:18:59 UTC

So far RMC is a file-based feature allowing developers to bring their own board-specific data in a directory where data, fingerprints and a bbappend file to RMC DB recipe.

Initial reviewer feedback suggests RMC should be able to grab artifacts generated from OE build or support generating that data itself. From RMC designer's perspective, I think we should keep RMC file-based approach in general. Generating files which is specific to a software project is also less flexible and costly in my opinion too.

It is still worthy to provide a way for RMC clients to bring these artifacts into RMC central database when they want. (Also remember RMC clients can construct their DB with function in rmc-db.bbclass.) In this way we can still keep RMC file-based.

--------original correspondence------------
[tom.zanussi@linux.intel.com]

If it's important to pick up data from the artifacts, then it would seem
that rmc should either be able to grab that data, or should be able to
generate that kind of data itself.  If rmc can only handle static
entries and something more is needed/expected by users, then it would
seem to be of limited use.

Comment 1 Tom Zanussi 2016-08-04 18:39:14 UTC

Just to be clear about the reason behind my original feedback quoted above, the original issue that prompted the comment was that there were originally two boot entries, one from rmc and the other from the build system.

When asked why there should be two, justification was that the other boot item from the build system would pick up data/configuration from the build artifacts, whereas boot items from rmc are restricted to being generated from static rmc configuration.

This raises the question on the one hand whether only static configuration for rmc is sufficient, given that users of the build system have grown used to/expect a more dynamic capability.  If that is the case, then where should this dynamic capability come from - should it interact at all with the build system?  If so, that interaction would presumably interface somehow with the build system artifacts.

If this is not the case, then it seems we have overlapping/duplicated capabilities.

Comment 2 Jianxun Zhang 2016-10-31 19:41:22 UTC

RMC works differently from traditional OE perspective which manage each board with a specific configuration.

The valid use case is to have a build support multiple types of board at run time. That means a software component must build artifacts for all supported boards and call RMC to construct a database with all of these artifacts.

The existing model is developers use OE interfaces (variables) to customize their board in every individual conf file. To support this, we need to find some way to let developer register different values of a _same_ variable for multiple boards. I think this change won't be easy.

For which artifact should be effective at run time, an artifact build from OE or another version in RMC database, it is up to the implementation in the software client using RMC. It could give RMC data a higher precedence or prefer any other data source to RMC data.

During the review, we have changed RMC to override boot entries from OE build. But this behavior could not be universal.

I would suggest to postpone this task later than other RMC enhancements. I just give a 5 day estimation here but it is very likely subject to change later.

Comment 3 Todor Minchev 2017-05-18 16:32:51 UTC

Does not apply to RMC2. Any file can be included in the data store by just copying it to the appropriate fingerprint directory.