Add support for device path protocol and EFI_LOCATE_DEVICE_PATH - #187
Conversation
|
Thanks for the contribution! I've made a separate PR (#188) which fixed the remaining CI issues, if you rebase (and skip the commit with the unstable feature rename), it should be green. |
…into device_path-dev
|
I believe (?) I rebased my pull branch, I'm not too familiar with doing PRs (or git in general, to be honest). I'm unsure why the |
|
You can run |
|
That doesn't seem to have made a difference. Running the command again results in no more formatting changes. |
|
See this: https://github.com/rust-osdev/uefi-rs/pull/187/checks?check_run_id=1511313923 |
|
Should be good to go now! |
|
There are a few lint warnings about missing documentation. Would it be possible to add some short doc comments for the items which lack them? |
|
I don't believe the linter is complaining about anything anymore :) |
device path protocol and EFI_LOCATE_DEVICE_PATH (for EFI_BOOT_SERVICES/BootServices)device path protocol and EFI_LOCATE_DEVICE_PATH
Motivation
This PR adds support for the
EFI_DEVICE_PATH_PROTOCOL, primarily for support with theEFI_LOCATE_DEVICE_PATHfunction, existing on theEFI_BOOT_SERVICESstructure.Changes
3 new types are added:
To facilitate usage of these types, and implementing the
EFI_LOCATE_DEVICE_PATHfunction, I added the following function to theHandlestruct:Additionally, I've broken
LoadedImageout into its ownloaded_image.rsfile, for the sake of semantically expanding the types held within the module. The new module format is well expressed by the following:This is obviously not a breaking change, so I felt taking this liberty (given the corollary nature of
EFI_DEVICE_PATH_PROTOCOLtoEFI_LOADED_IMAGE_PROTOCOL) was acceptable.The final change is to update the feature
optin_builtin_traitstoauto_traits, as the feature name has breaking-changed. There already exists a PR for this, but I was unaware of it at the time of the commit.