Bug 10638

Summary: RMC: Refactoring database generation in rmc.bbclass
Product: [Build System, Metadata & Runtime] BSPs Reporter: Jianxun Zhang <jianxun.zhang>
Component: bsps-meta-intelAssignee: Todor Minchev <todor.minchev>
Status: RESOLVED OBSOLETE QA Contact:
Severity: enhancement    
Priority: Medium CC: bluelightning, sgw
Version: 2.2   
Target Milestone: 2.4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Bug Depends on: 11323    
Bug Blocks:    

Description Jianxun Zhang 2016-11-09 20:13:58 UTC
The current implementation in rmc.bbclass is a shell function. It packs fingerprint and data based on board directories fed into the interface variable by RMC users.

But it is possible that two board directories contain same fingerprint of a type of board but with same filenames for RMC data. This will cause two RMC records for a type of board packed in RMC database.

The RMC tool cannot make judgement. The current solution in rmc is to go through all records for the board and pick up the first matched file blob for the board at run time.

This brings ambiguity because the order of records is actually determined by how build system generates the database. It is not obvious which will be fetched between two file blob, with same file name, in two records at run time.

I suggest we change the logic in rmc.bbclass into a python function which can consolidate data in different board directories into a single record when they have same fingerprint. It can also show developer a warning message at build time to prompt the potential conflict between blobs. (e.g. when one BSP layer tries to override a file blob from lower layers.)

In a short, only one RMC record will be generated for a type of board.
Comment 1 Todor Minchev 2017-05-18 16:36:56 UTC
Does not apply to RMC2.