[U-Boot] [PATCH 4/8] cmd: avb2.0: avb command for performing verification

[Simon Glass <sjg@chromium.org>]

Hi Igor,

On 16 May 2018 at 02:20, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
> Hi Simon,
>
>> If there is no need for operations and indirection through function
>> pointers, why not just call the functions directly?
>
> This is the way how libavb is integrated into bootloader. libavb interfaces with
> the bootloader through the supplied AvbOps struct. This includes operations to
> read and write data from partitions, read and write rollback indexes, check
> if the public key used to make a signature should be accepted, and so on.
> This is what Google AVB 2.0 specification says.
> For additional details please check [1].
>
> In this particular patch, all avb commands, except the main "avb
> verify", are used
> to debug these particular callback implementations
> (can be used when enabling this feature on new platform etc.).
> The reason I use indirection through function pointers is that they
> are not supposed
> to be public, and are not intended to be used somehow directly, only by libavb
> (check [2] how libavb is using it)
>
>>> (I've left a notice in the cover letter that checkpatch
>>> will fail on the commit, which introduces libavb; also, there is the ongoing
>>> discussion there regarding why libavb/libavb_ab should be
>>> kept as it's. Please join us, if you don't mind).
>>
>> I do see the cover letter thread but could not find the camel case
>> discussion. Can you please point me to it?
>
> There is no any particular discussion about CamelCase, but a few general
> statements why I should avoid introducing any changes in
> libavb/libavb_ab libraries.
> Regarding our particular case, AvbSlotVerifyResult and AvbSlotVerifyData types
> (I guess you're talking about these CamelCase instances) are defined inside
> libavb library, so obviously I can't simply replace it with something, that
> conforms to the Linux kernel coding style

Maybe I've lost track of the patches, but I thought you were
implementing this library in U-Boot and thus can call things whatever
you like?

We have had a similar thing with EFI, but in that case there was no
reference code to use, so it was easier to just rename things to
kernel style.

In this case it seems that you want to be able to easily merge changes
back and forth between U-Boot's copy of the library and the upstream
one.

I think we have to balance that desire against the impact of having
non-conforming code in the U-Boot code base. So far we have tended to
adjust the code to fit kernel style in these situations.

Anyway I think this is Tom's call and I'm happy with whatever he decides.

[..]

Regards,
Simon