Open MOZGIII opened 5 years ago
I am curious, while it's true that the efivar wrappers could probably be thinner, what would be a use-case for direct access to the winapi/efivarfs/nvram implementations?
I don't have a concrete use case example in mind, but the rationale for providing low level implementations is to let users to consume the API in ways different to those that the unified wrapper would allow. An example for that would be to allow user to get just the attributes for a var with an efivar
(not efivarfs
) backend, or enumerate both the names and values in a single operation (via nvram
command on macOS).
The benefit of this approach is that it'd be possible to provide a low-overhead, as close to the backend as possible, implementations while also providing easy to use but limited (to the "lowest common denominator" of the all backends) unified API.
In addition, the low-level parts should be able to evolve individually, and gain additional features, that are not currently implemented because they're not required for the unified API (or for various other reasons). Actually, this is where I see the most value from the split-up.
As a way for the future improvements, I'd love to have access to low-level implementation details, for the cases where I have to perform low-level operations.
I'd propose the following structure:
All the low-level crates should provide the interface that makes the most sense for a particular implementation. For example, windows implementation would just provide rust-safe wrappers for read var and write var operations, without any boilterplate like
VarManager
etc. To be more specifc, for write variable functionality only a thin rust-safety wrapper aroundSetFirmwareEnvironmentVariableExW
would be required.For the high-level
efivar
the idea of the interface would be the same, but the internal implementation would utilize other crates with the low-level implementations and wrap them up for the unified API.This would be useful to build up a more feature-full rust crates ecosystem for working with efi variables.