The initial feedback to RMC feature during submission is user could make mistakes easily but hard to debug them at build time. We should allow SW components calling RMC to verify the data in their way. The biggest challenge is how to keep simplicity when adding new functions in RMC per my opinion. I don't think RMC could catch typos but something like checking non-existing files should be one of the good points. -----------------original correspondence ----------------- [tom.zanussi@linux.intel.com] I was easily able to accidentally create nonsense configuration and nothing told me it was wrong. For example, in my BOOTENTRY.CONFIG I mistyped a filename that didn't exist: doesntexistboot.conf It would seem that would be something the user would definitely be interested in knowing (along with any other errors in .conf files themselves), especially since there doesn't seem to be any way on the target to tell what the source of the problem is. It seems you should be able to detect that when generating the db file on the host at least. Basically there doesn't seem to be any way to determine the cause of problems other than inspection, which is going to cause lots of complaints from users.
Does this also cover run-time verification?
No. I think what covered now is for build time checker. I feel so far our discussion is still at high level for what we should do to improve runtime robustness.
Capturing the last comments on the meta-intel rmc thread bringing things past the high level to improve runtime robustness. Also changed the title of this bug to include runtime considerations. >>> The installer show deployment information in console. I don’t think bootloader should fail or toss warning message when there is no data or db for a board. Or are you suggesting anything else? Please feel free to assign me a ticket as a following up. >>> >> >> You modify the bootloader to call libraries to gather data from the >> board and query the rmc db. The libraries and the database itself can >> be buggy or corrupt, and cause unintended failures. How does the user >> differentiate a failure from these causes vs an expected lack of >> configuration? > > We start troubleshoot SW problems when we start to believe we did right but cannot get expected result. RMC is just another piece of software, so no difference here. If user believes everything is correct but SW doesn’t work as expected/documented, it is time to debug. > > You just remind me that Cal once asked me to add some dumpers to convert binaries (fingerprint and db) back to human-readable blobs for troubleshooting. I created another ticket for this request. > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10092 > Yes, that would definitely help a lot. > But I don’t think these efforts will be capable of differentiating all unexpected results from wrong input and SW bug. > It would probably be enough to have a settable mode that would be verbose about what it was doing. Combined with the dumper, I think that would be enough so that most of the time you could figure out what's going on without resorting to a debugger or adding printfs to the code..
This could be another major work in rmc recipes. There are some RMC enhancements should be addressed first before we can start to design the interfaces of these checkers to the outside of RMC. I think it is difficult to estimate a target milestone at this point. Set milestone to future.
Does not apply to RMC2.