[PATCH 00/13] efi: Tidy up confusion between pointers and addresses

Simon Glass sjg at chromium.org
Tue Nov 26 16:39:05 CET 2024


Hi Heinrich,

On Tue, 26 Nov 2024 at 02:10, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 25.11.24 21:44, Simon Glass wrote:
> > The EFI-loader implementation converts things back and forth between
> > addresses and pointers, with not much consistency in how this is done.
> >
> > Within most of U-Boot a pointer is a void * and an address is a ulong
>
> No. It is phys_addr_t that was introduced to handle the sandbox's
> virtual addresses.
>
> And we should keep this sandbox stuff out of the EFI code. They are only
> needed for the command line interface.

No. My statement is correct and long predates sandbox. U-Boot has
always used ulong. Using an address is generally much easier than a
pointer, so I believe this design decision was (and remains) a good
one. I certainly would not support changing it. The phys_addr_t type
has nothing to do with sandbox.

>
> >
> > This convention is very helpful, since it is obvious in common code as
> > to whether you need to call map_sysmem() and friends, or not.
> >
> > As part of cleaning up the EFI memory-management, I found it almost
> > impossible to know in some cases whether something is an address or a
> > pointer. I decided to give up on that and come back to it when this is
> > resolved.
> >
> > This series starts applying the normal ulong/void * convention to the
> > EFI_loader code, so making things easier to follow.
>
> According to the C specification size of long may be different to the
> size of void *. uintptr_t is the type that is guaranteed to match the
> size of void *.
>
> There is no benefit in spreading the ulong abuse any further.

U-Boot specifically uses compilers where ulong can hold a pointer.
Same with Linux.

Regards,
Simon


More information about the U-Boot mailing list