[U-Boot] [PATCH] efi_loader: allow efi_loader code to call EFI interfaces

[Alexander Graf]

On 25.07.17 18:18, Rob Clark wrote:
> On Tue, Jul 25, 2017 at 10:28 AM, Alexander Graf <agraf at suse.de> wrote:
>>
>>
>> On 25.07.17 14:28, Rob Clark wrote:
>>>
>>> On Tue, Jul 25, 2017 at 8:16 AM, Alexander Graf <agraf at suse.de> wrote:
>>>
>>>> I personally think having _ext functions in anything exposed to UEFI
>>>> payloads makes more sense.
>>>>
>>>
>>> having 2x all the interfaces for file related protocols would be
>>
>>
>> Why 2x the interfaces?
> 
> well, maybe not all, but for efi_load_image() from a device-path to
> work, we need to be able to use simple-filesystem-protocol and a bunch
> of the file-protocol interfaces.. so it is definitely more messy.
> 
>>> unfortunate.  (Also currently they can stay static in efi_file.c and
>>> just be called via same efi_file_handle fxn ptrs that the UEFI world
>>> would be using, which is kinda nice.)
>>
>>
>> Ah, that indeed is nice.
>>
>> So, there is a third option if you want to tackle it:
>>
>>    3) Remove register variable need for gd
>>
>> If gd is a simple global variable rather than a register variable, we
>> wouldn't have that problem. On x86 it's just a variable for example. I don't
>> know why arm and aarch64 have it as register variable, but I can't see an
>> immediate need for it.
>>
>> If you manage to solve that, we don't need any ext functions or reference
>> counters ;).
> 
> 
> It would be nice to not have this gd mess.. although I'm going to
> leave it to someone else who understands better why we do that in the
> first place to solve.  I have a big pile of display-handover

Yeah, that was my plan too when I introduced efi_loader. Maybe I'll find 
time to tackle it one day. But it's certainly nothing short-term :(.

> (clk/powerdomain/display-controller-state) issues on my TODO list, and
> I'm just trying to get the bootloader sorted to the point where I can
> tackle that.  Not to mention a big pile of things todo in mesa, and my
> actual $day_job.

No worries, we're all in the same boat :)

> I think with the EFI interfaces I need to use for efi_load_image, it
> should be easy enough to keep any of those from calling back into the
> UEFI world, and we could do some sort of EFI_CALLBACK() macro with
> some extra error checking to safeguard instead of the
> EFI_EXIT()+callback+EFI_ENTER() pattern.. and while it is a bit
> annoying to have to be careful about that, I think it would work ok if
> no one has a solution for the gd mess in sight.

If you want to macrorize things to make them more readable, give it a 
try :).

I really don't mind which path to take, but I want to ensure we're 
consistent and only have a single way of dealing with entry/exit to 
worry about.


Alex