3 ms·
Nice /s, it's not idiomatic: pub struct QueueContext { buffer: PVOID, length: usize, timer: wdf::Timer, current_request: WDFREQ
by zamalek 3y ago
Nice /s, it's not idiomatic:
pub struct QueueContext {
buffer: PVOID,
length: usize,
timer: wdf::Timer,
current_request: WDFREQUEST,
current_status: NTSTATUS,
spin_lock: wdf::SpinLock,
}
- kramerger 3y agoI think they would need to rewrite everything to get rid of that
- deleted 3y ago[deleted]
- BaculumMeumEst 3y agocould you clarify what you mean?
- Grimburger 3y agoIdiomatic rust - https://rust-unofficial.github.io/patterns/idioms/index.html https://rust-unofficial.github.io/patterns/idioms/index.html
- c7DJTLrn 3y agoDoesn't use Rust naming convention, imports Windows' PVOID (void pointer) type, when Rust's whole purpose is not to have unsafe pointers.
- jeroenhd 3y agoAlmost all of those refer back to FFI integer types, because that's what the Windows driver API uses. The Linux kernel has similar issues when it comes to writing Rust drivers, and so does every other project interoperating with C. Types like NTSTATUS have a significant amount of documentation attached to it. Unlike C and C++, you can't just assign an integer value to an enum value. I suppose they could've generated a wrapper class and required you to cast every time, but then you'd get code that's 50% .into()s and that would probably add overhead to your driver as well. As far as I can tell, you never set or alter these enum values, other than maybe the void* for buffer; you only ever read from them. A match {} block should work just fine on NTSTATUS. WDFREQUEST is a handle, so you can't really do anything with it other than maybe swap it out for another handle of the same type. Timer and SpinLock have been converted into idiomatic Rust objects, wrapping unsafe library calls in their bodies. Other than that, I don't really see how you'd make this code idiomatic without adding a significant performance burden.
- zamalek 3y ago> Types like NTSTATUS have a significant amount of documentation attached to it. I don't think Rust developers would have problems with converting NtStatus to NTSTATUS for the sake of searching documentation.
- jeroenhd 3y agoThese are automatically generated bindings. Someone could go over every typedef and correct the spelling but I doubt any Rust developer would have problems with using a few capitals here and there.
- alexchamberlain 3y agoI think it would have been nicer if this platform took the enum, and didn't the integer conversion at the FFI level, no? That should all be elided by optimisations.
- jeroenhd 3y agoNTSTATUS is actually a combination of five types of information: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/87fba13e-bf06-450e-83b1-9241dc81e781 https://learn.microsoft.com/en-us/openspecs/windows_protocol... The first two bits indicate severity, the next bit identifies if it was OS generated or not, then there's an indicator to see if it can be turned into a HRESULT or not, then a bunch of bits indicating the source of the error, and lastly the error code relevant given the previously set bits. The Windows status codes could be converted, but the status codes generated by other drivers can't be. Even then the conversion would be far from free, you'd need to keep a close eye on your optimisations with every compiler version to keep them free. That also ignores the possibility programs have to classify their own status codes, so you'd need some kind of "unconvertible" object to indicate that you can't reliably parse the faculty ID, and that you have to treat it like a simple integer.
- IshKebab 3y agoWhat were you expecting exactly?