Add an EtwDriverProvider for Windows kernel-mode support. #39
Conversation
Without this, building/testing with --all-features fails. TBD if there is a better solution.
|
@sivadeilra Review when you have a chance? The feature gating I've landed on here is a little messy. Perhaps it makes more sense to split this into a separate crate entirely? |
This shouldn't be an issue. GitHub runners already have the WDK preinstalled. |
| //!win_etw_provider = { version = "^0.1.11", default-features = false, features = "windows_drivers" } | ||
| //! ``` | ||
| //! | ||
| //! Then apply the `#[trace_logging_provider_kernel]` macro rather than `#[trace_logging_provider]`. |
There was a problem hiding this comment.
Rather than having a different proc macro, I think it would be better to have a single proc macro that generated code that would work for either user-mode or kernel-mode. If necessary, that code could use macros (not proc macros, ordinary macros) that are defined in win_etw_provider to handle some specialization for the environment.
I haven't skimmed the PR enough to see how different the output code is per environment, but my hope is that this can be unified.
Today, this repo relies on the user-mode Windows APIs for enabling ETW tracing. While this is all fine and dandy in userland, as we continue to invest in Rust support for kernel-mode components this naturally blocks us from using this crate to run ETW tracing in Rust drivers.
To alleviate this issue, this PR introduces a new
EtwDriverProviderimplementation of the Provider trait. Fortunately for us, the driver API for tracing is almost 1:1 with the user-mode API, which meansEtwDriverProvider.rsis largely copied and pasted from the existingprovider.rsimplementation. Then we just genericize the macro generation a bit and we're good to go.The biggest complication here is actually related to building. We need a dependency on the
wdk-syscrate (see https://github.com/microsoft/windows-drivers-rs) to successfully build and link the kernel-mode DDIs. However, building this crate requires a full Windows Driver Kit installation and LLVM. We obviously do not want that to become mandatory for all developers to install to use the user-mode aspects of this crate.As such, this PR introduces two new features to win_etw_provider and win_etw_macros:
windows_apps, which is a default feature, andwindows_drivers, which is not. Building the driver-related components is locked behind CFG gates forwindows_driversbeing active andwindows_appsnot being active. Thus the only way to activate the driver support - and the WDK requirements - is to explicitly opt in to the windows_drivers feature and to opt-out of standard behavior. This prevents this change from breaking existing workflows, but it does mean that building the driver support becomes a specific separate case from building the crate normally and not a standard additive feature.An additional caveat: the GitHub automation will not automatically build driver support, as we would need to spin up WDK images as well. This isn't impossible (again, see windows-drivers-rs) but would significantly complicate this PR.