Bug 10081

Summary:	RMC: Have checker mechanism so that clients SW can verify board-specific data at build-time and run-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:02:17 UTC

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.

Comment 1 Tom Zanussi 2016-08-04 18:29:33 UTC

Does this also cover run-time verification?

Comment 2 Jianxun Zhang 2016-08-05 01:05:10 UTC

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.

Comment 3 Tom Zanussi 2016-08-05 19:21:46 UTC

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..

Comment 4 Jianxun Zhang 2016-10-31 19:55:35 UTC

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.

Comment 5 Todor Minchev 2017-05-18 16:40:26 UTC

Does not apply to RMC2.