Hi Heinrich,
On 17 September 2017 at 22:47, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 09/18/2017 12:59 AM, Simon Glass wrote:
This function repeats data structures provided by driver model. They are only created once so can be stale if the EFI loader is called twice (e.g. for testing or on boot failure).
Add a TODO to address this. It should be possible to attach EFI devices and data structures to driver-model devices and avoid having a parallel set of data structures.
Signed-off-by: Simon Glass sjg@chromium.org
cmd/bootefi.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 9aa588eb1b..ee07733e3e 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -109,6 +109,10 @@ static struct efi_object bootefi_device_obj = { /**
- efi_init_obj_list() - Initialize and populate EFI object list
- TODO(sjg@chromium.org): Move this to a dynamic list based on driver model,
- so that it does not need to be created before running EFI applications
- and updates when devices change.
I am not quite sure if by dynamic list you refer to linker generated lists or to hot plugging.
The UEFI spec 2.7 has a chapter on "Hot-Plug Events". This would add a lot of complexity. I do not think that we currently need it.
The object list also gets new entries created by the EFI application via calling InstallMultipleProtocolInterfaces of InstallProtocolInterface with *handle == NULL.
Here I am referring to what I see as duplicate device tables, brought in from driver model. I am wondering if we can make the EFI info come from the driver-model directly.
Regards, Simon