Open joaoviictorti opened 1 month ago
From what I've analyzed, the PsGetCurrentThread
API uses the CFORCEINLINE
macro. As the library doesn't use the .generate_inline_functions(true)
option in the bindgen, the correct bindings are not generated for this API. The bindgen may even generate the bindings, but it ends up not putting #[inline]
, for example.
I saw some discussions on rust-bindgen
GitHub about this issue and I also noticed that someone made a pull request in the windows-driver-rs
repository related to problem #51. I still don't know how this pull request is progressing, but the question about the file system filter APIs remains. Anything I can do a pull request on, I look forward to hearing back! 😁
does it contain all the APIs documented by Microsoft for Windows kernel drivers using Rust?
Not currently. We are planning on expanding api coverage, grouping headers into functional areas (ex. I have a branch adding all the headers related to HID. I'd consider PRs expanding coverage, but will not review them until after #186 merges. With that said, PsGetCurrentThread
is in ntddk.h
, which is already included.
From what I've analyzed, the PsGetCurrentThread API uses the CFORCEINLINE macro. As the library doesn't use the .generate_inline_functions(true) option in the bindgen, the correct bindings are not generated for this API. The bindgen may even generate the bindings, but it ends up not putting #[inline], for example. You're right in that
PsGetCurrentThread
is not currently generated because it is an inline function.generate_inline_functions
doesnt help here because it would have no implementation to link to. The experimentalwrap_static_fns
may work, but I haven't tested it. For more info: https://rust-lang.github.io/rust-bindgen/faq.html#why-isnt-bindgen-generating-bindings-to-inline-functions.
Now that #186 is merged, what are the guidelines for adding new APIs?
I, for example, need the UDECX API. This API also uses a function table UdecxFunctions
, so like for WDF there are no direct bindings. I generalized the call_unsafe_wdf_function_binding_impl
macro in wdk-macros
in order to support both WDF and UDECX and updated the wdk-sys
build to include the relevant USB and UDECX headers. I doubt this is the right way to go especially following the changes introduced by #186... Perhaps such APIs deserve a crate of their own? Or, if we still want them under wdk-sys
, can we opt them in/out with crate features?
Hi guys.
I have a question about the library: does it contain all the APIs documented by Microsoft for Windows kernel drivers using Rust? I noticed that I didn't find some APIs in the library, like PsGetCurrentThread and Minifilters. I know that I can make the connection manually and call the function in the code, but I wondered if that was the intention of not having them. I'm thinking of making a Pull Request related to this, but I wanted to clear this doubt first.