On 25.07.17 18:18, Rob Clark wrote:
On Tue, Jul 25, 2017 at 10:28 AM, Alexander Graf <ag...@suse.de> wrote:
On 25.07.17 14:28, Rob Clark wrote:
On Tue, Jul 25, 2017 at 8:16 AM, Alexander Graf <ag...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
