[U-Boot] [PATCH v3 3/3] efi_loader: implement OpenProtocolInformation

[Alexander Graf]

On 13.08.17 21:32, Heinrich Schuchardt wrote:
> On 08/13/2017 09:24 PM, Alexander Graf wrote:
>>
>>
>> On 13.08.17 13:17, Heinrich Schuchardt wrote:
>>> On 08/12/2017 03:38 PM, Alexander Graf wrote:
>>>>
>>>>
>>>> On 05.08.17 22:32, Heinrich Schuchardt wrote:
>>>>> efi_open_protocol_information provides the agent and controller
>>>>> handles as well as the attributes and open count of an protocol
>>>>> on a handle.
>>>>>
>>>>> Cc: Rob Clark <robdclark at gmail.com>
>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>
>>>> Do you have an application that leverages these interfaces? Would it be
>>>> possible to add that application to our travis tests?
>>>>
>>>>
>>>> Alex
>>>>
>>>
>>> iPXE (snp.efi) uses the functions but there are other things missing to
>>> make it really working.
>>
>> Ah, I see. How much is missing to make that one work for real?
> 
> Before reaching the input prompt ConnectController and
> DisconnectController fail for the Simple Network Protocol.
> 
> So I am not able to say if the network connection will work.
> 
> For testing we will need an iSCSI target.
> 
>>
>>> Putting new tests into the executable created by
>>> CMD_BOOTEFI_HELLO_COMPILE would be possible but that seems messy to me.
>>>
>>> Should we replace CMD_BOOTEFI_HELLO_COMPILE by an option that creates
>>> multiple executables for the different EFI API functions we have to test?
>>>
>>> Each test then should consist of:
>>> - start QEMU system
>>> - download dtb and test executable from tftp server
>>> - start the test executable
>>> - evaluate console output
>>> - shutdown QEMU system
>>
>> We have most of the above already in travis today. All we would need is
>> to extend it to download a built iPXE binaries and add test snippets to
>> tests/py for iPXE functionality.
> 
> Proving that some binary runs is not enough to test the different corner
> cases of this complex API.
> 
> I would prefer to have a bunch of test binaries compiled from the U-Boot
> git tree.

Sure, even better in my book ;). Ideally we would have both. Unit tests 
to check individual interfaces and integration tests to make sure we 
don't regress real world use cases.


Alex