First, my code "does" use the VBOOT 2.1 library from vboot_reference. I am little held up with getting permissions to vboot_reference repo. Once that is done, I am planning to raise a review there with the new utilities we implemented (with all the original utilities untouched :-)).
Oh, okay, I didn't realize that. That's all the more reason we should talk. We are generally happy about taking external submissions to the vboot project, but if you just turn up with a huge code dump without prior discussion, that would likely be a problem.
Also, the logic using VBOOT 2.1 libraries in vboot_logic_ex.c is the new logic we are introducing without interfering with the existing logic in vboot_logic.c. We are also thinking of a similar implementation as you mentioned above to make the the verification more flexible and generic.
Right, that's one of my main concerns here... you're introducing this huge new thing on the side that duplicates/forks a lot of code and doesn't really interact with the old version. We don't want to maintain many different versions of vboot logic that all do somewhat the same things in a slightly different way, we'd rather organically evolve a single version forward to eventually support all the different use cases people have, where only the code that actually needs to be different for that is different.
I very much welcome the idea of a meeting between the concerned parties so we can discuss this implementation in detail and discuss any potential changes to it. Please let me know how we can co-ordinate towards this meeting.
Okay, great. I would suggest a Google Hangouts VC at a PDT and Asia friendly time (so Joel can join us if he wants to) if that works for you. How about some time next week at 5pm? Maybe Monday? (Also asking others here in case you are interested in this.)
To view, visit change 32159. To unsubscribe, or for help writing mail filters, visit settings.