Page MenuHomeFreeBSD

[RFC] Split EFI map parsing code to a common file
Needs ReviewPublic

Authored by mhorne on Mon, Nov 25, 10:09 PM.
Tags
None
Referenced Files
F103977084: D47746.diff
Sun, Dec 1, 11:20 PM
Unknown Object (File)
Wed, Nov 27, 4:12 PM
Unknown Object (File)
Tue, Nov 26, 12:31 PM
Subscribers

Details

Summary

Motivation: I would like to enable the EFI map parsing on riscv, which
is preferable to parsing memory regions from the device tree. I could
easily duplicate the functionality, but it can be shared without much
extra effort.

In this commit, the arm64 code is moved to the new file, and enabled for
that platform. No functional change intended.

The memreserve/kboot early map parsing is necessarily moved as well, but
is not inherently machine-dependent. I gated it behind a feature flag,
EFI_HAS_MEMRESERVE. Naming and placement is up for discussion. Note: the
argument to exclude_efi_memreserve() is changed to a vm_paddr_t, the
more correct type.

armv7 is yet unchanged; there are slight differences in its (older)
version of the map parsing code, so testing is required to enable it,
but this would be the plan in the near term.

amd64 could be converted to use this interface too, but it doesn't use
the common "physmem" interfaces for managing physical memory, and would
therefore require further tweaks. I am not inclined to make this change
right away.

Further: struct efi_map_header and struct efi_fb can be de-duplicated,
and don't really belong in metadata.h.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 60770
Build 57654: arc lint + arc unit

Event Timeline

sys/kern/subr_efi_map.c
1

Need copyright and license

177

I think this is only on arm64.
It's only used, even in Linux, for the gicv3, so I'm not sure it belongs here...
So if it's easy, I'd prefer this remains in arm and uses this generic mechanism.

sys/sys/efi_map.h
1

Need copyright and License

sys/kern/subr_efi_map.c
1

Of course. Figuring out the copyright list requires a bit of investigation.

177

If it has no hope of reuse then no problem, I'll split it differently. My thinking was that they may find other reasons to use this interface in the future.