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.
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.
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.
Does not apply to RMC2. Any file can be included in the data store by just copying it to the appropriate fingerprint directory.