Add (Un)Installing Multiple Protocol Interfaces #675
Conversation
| /// * [`uefi::Status::ALREADY_STARTED`] | ||
| /// * [`uefi::Status::INVALID_PARAMETER`] | ||
| /// * [`uefi::Status::OUT_OF_RESOURCES`] | ||
| pub fn install_multiple_protocol_interfaces(&self, handle: Handle, mut args: ...) -> Result { |
There was a problem hiding this comment.
I think we should either mark this as unsafe, as we do not guarantee any type-safety here, or do not support the UEFI function at all but build a custom solution around install_protocol_interface, which is well typed.
What do you think, @nicholasbishop ?
There was a problem hiding this comment.
Is it possible to construct a VaList in Rust? I don't see a way after looking at the docs a bit but I'm not that familiar with the feature. Basically what I'm thinking is, we'd have the safe wrapper here take a slice of (&Guid, *mut c_void) pairs, then convert that into a valist for calling the underlying UEFI function.
If we can't do that, then I think marking this function unsafe is the right thing to do.
Incidentally, I have previously wondered why InstallMultipleProtocolInterfaces matters since it seems like you could just call InstallProtocolInterface multiple times. https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#driver-model-boot-services says:
The third group of boot services is designed to help simplify the implementation of drivers, and produce drivers with smaller executable footprints. [...] The EFI_BOOT_SERVICES.InstallMultipleProtocolInterfaces() and EFI_BOOT_SERVICES.UninstallMultipleProtocolInterfaces() are very useful to driver writers. These boot services allow one or more protocol interfaces to be added or removed from a handle. In addition, InstallMultipleProtocolInterfaces() guarantees that a duplicate device path is never added to the handle database. This is very useful to bus drivers that can create one child handle at a time, because it guarantees that the bus driver will not inadvertently create two instances of the same child handle.
There was a problem hiding this comment.
I think we should either mark this as unsafe, as we do not guarantee any type-safety here, or do not support the UEFI function at all but build a custom solution around
install_protocol_interface, which is well typed.What do you think, @nicholasbishop ?
This can potentially a solution. But I will look into passing variadic arguments for this function.
| @@ -58,7 +58,7 @@ | |||
| //! [`uefi-services`]: https://crates.io/crates/uefi-services | |||
| //! [unstable features]: https://doc.rust-lang.org/unstable-book/ | |||
|
|
|||
| #![feature(abi_efiapi)] | |||
| #![feature(extended_varargs_abi_support)] | |||
There was a problem hiding this comment.
This will need to be gated behind the unstable feature since we are looking to transition to the stable channel by default in 1.68. See the following cfg_attr line for what that looks like.
| /// * [`uefi::Status::ALREADY_STARTED`] | ||
| /// * [`uefi::Status::INVALID_PARAMETER`] | ||
| /// * [`uefi::Status::OUT_OF_RESOURCES`] | ||
| pub fn install_multiple_protocol_interfaces(&self, handle: Handle, mut args: ...) -> Result { |
There was a problem hiding this comment.
Is it possible to construct a VaList in Rust? I don't see a way after looking at the docs a bit but I'm not that familiar with the feature. Basically what I'm thinking is, we'd have the safe wrapper here take a slice of (&Guid, *mut c_void) pairs, then convert that into a valist for calling the underlying UEFI function.
If we can't do that, then I think marking this function unsafe is the right thing to do.
Incidentally, I have previously wondered why InstallMultipleProtocolInterfaces matters since it seems like you could just call InstallProtocolInterface multiple times. https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#driver-model-boot-services says:
The third group of boot services is designed to help simplify the implementation of drivers, and produce drivers with smaller executable footprints. [...] The EFI_BOOT_SERVICES.InstallMultipleProtocolInterfaces() and EFI_BOOT_SERVICES.UninstallMultipleProtocolInterfaces() are very useful to driver writers. These boot services allow one or more protocol interfaces to be added or removed from a handle. In addition, InstallMultipleProtocolInterfaces() guarantees that a duplicate device path is never added to the handle database. This is very useful to bus drivers that can create one child handle at a time, because it guarantees that the bus driver will not inadvertently create two instances of the same child handle.
This (currently draft) PR proposes the addition for support for missing functions
EFI_BOOT_SERVICES.InstallMultipleProtocolInterfaces()andEFI_BOOT_SERVICES.UninstallMultipleProtocolInterfaces().This was previously blocked due to lack of support for varargs in EFIAPI. (Still need some assistance on the actual wrapper implementation).
Currently blocked on regular functions not supporting variadics, probably need to find a workaround for this.
Checklist