10638 2016-11-09 20:13:58 +0000 RMC: Refactoring database generation in rmc.bbclass 2017-05-18 16:36:56 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-meta-intel 2.2 x86 Multiple RESOLVED OBSOLETE Medium enhancement 2.4 11323 1 jianxun.zhang todor.minchev bluelightning sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 68204 0 jianxun.zhang 2016-11-09 20:13:58 +0000 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. 73341 1 todor.minchev 2017-05-18 16:36:56 +0000 Does not apply to RMC2.