Stories with Tag Driver

• Writing a simple windows driver in Rust

  permalink

  Posted: 2025-02-08 17:25:03

  Verbose tl;dr

  This blog post details creating a basic Windows driver using Rust. It leverages the windows crate for Windows API bindings and the wdk-sys crate for lower-level WDK access. The driver implements a minimal "DispatchCreateClose" routine, handling device creation and closure. The post walks through setting up the Rust development environment, including Cargo configuration and build process adjustments for driver compilation. It highlights using the wdk-build crate for simplifying the build process and generating the necessary INF file for driver installation. Finally, it demonstrates loading and unloading the driver using the DevCon utility, providing a practical example of the entire workflow from development to deployment.

  This blog post details the process of creating a rudimentary Windows driver using the Rust programming language, walking through the necessary steps and explaining the underlying concepts involved. The author begins by emphasizing the challenges traditionally associated with Windows driver development, particularly the complexities and potential pitfalls of using C and C++. They then introduce Rust as a safer and more modern alternative, highlighting its memory safety features and robust tooling as key advantages.

  The post proceeds with a practical demonstration, outlining the setup required for Rust-based driver development. This includes installing the necessary build tools, configuring the development environment, and incorporating the windows-rs crate, a crucial library providing Rust bindings for Windows APIs. The specific dependencies and their purposes are explicitly mentioned, such as the wdk-sys crate for accessing the Windows Driver Kit (WDK) and the windows crate for general Windows API interaction.

  The core of the driver's functionality is then explained, revolving around a simple kernel-mode "Hello, world!" example. The author elaborates on the structure of the driver code, demonstrating how to define an entry point function (DriverEntry) and how to utilize the DbgPrint macro for logging output to the debugger. The post meticulously describes the process of building the driver using cargo and the associated build configuration necessary for targeting the Windows kernel environment. The build process involves specifying the target architecture and linking against the appropriate WDK libraries.

  Following the successful compilation of the driver, the post details the steps for deploying and testing it. This includes loading the driver using a tool like devcon and verifying its functionality by observing the "Hello, world!" message in the debugger output. The author emphasizes the importance of using a debugger like WinDbg or KD for effective driver debugging and testing. Furthermore, the post briefly mentions the potential use of Virtual Machines for a more isolated testing environment, acknowledging the inherent risks associated with kernel-mode driver development.

  Finally, the author concludes by reiterating the advantages of using Rust for Windows driver development, highlighting its potential for enhancing driver security and reliability. They also acknowledge that the ecosystem for Rust-based driver development is still relatively nascent but express optimism about its future growth and potential. The overall tone suggests that Rust offers a promising pathway towards simplifying and improving the often-complex world of Windows driver development.

  • Rust
  • Windows
  • Driver
  • Kernel
  • Operating System
  • Systems Programming
  • Low-Level Programming
  • Device Driver
  • Windows Driver Model (WDM)
  • Kernel-Mode Driver
  • WDF
  • Rust for Windows

  Summary of Comments ( 83 )
  https://news.ycombinator.com/item?id=42984457

  Verbose tl;dr

  Hacker News users discussed the challenges and advantages of writing Windows drivers in Rust. Several commenters pointed out the difficulty of working with the Windows Driver Kit (WDK) and its C/C++ focus, contrasting it with Rust's memory safety and modern tooling. Some highlighted the potential for improved driver stability and security with Rust. The conversation also touched on existing Rust wrappers for the WDK, the maturity of Rust driver development, and the complexities of interrupt handling. One user questioned the overall benefit, arguing that the difficulty of writing drivers stems from inherent hardware complexities more than language choice. Another pointed out the limited use of high-level languages in kernel-mode drivers due to real-time constraints.

  The Hacker News thread for "Writing a simple windows driver in Rust" (https://news.ycombinator.com/item?id=42984457) contains several comments discussing the challenges and advantages of using Rust for Windows driver development.

  One commenter highlights the difficulty of writing Windows drivers in general, regardless of language, due to the complexity of the Windows Driver Model (WDM). They point out that even seemingly simple tasks can become convoluted due to the asynchronous nature of driver operations and the need to manage IRQLs (Interrupt Request Levels). They also suggest that the article simplifies the process considerably.

  Another commenter mentions that Rust's ownership and borrowing system, while beneficial for memory safety, can introduce complexities when dealing with shared resources, a common scenario in driver development. They further explain that this can lead to challenges when implementing interior mutability, a pattern often employed in concurrent programming, potentially making Rust less ergonomic than C++ in certain driver development scenarios.

  Several commenters discuss the trade-offs between using Rust and C/C++ for driver development. Some appreciate Rust's memory safety features and modern tooling, viewing them as significant advantages over the error-prone nature of C/C++. Others express skepticism about Rust's suitability for driver development due to its steeper learning curve and potential performance overhead.

  A significant portion of the discussion revolves around the immaturity of the Rust ecosystem for Windows driver development. Commenters point to the lack of mature libraries and tooling compared to the well-established C/C++ ecosystem. They also raise concerns about the potential instability of the Rust for Windows project and the challenges of integrating Rust code with existing C/C++ driver codebases.

  One commenter discusses the performance implications of using Rust, noting that while Rust can achieve comparable performance to C/C++, it requires careful optimization and awareness of potential pitfalls, like excessive copying due to Rust's move semantics.

  Finally, a few comments delve into the specific technical details mentioned in the article, such as the use of the windows crate for interacting with Windows APIs and the challenges of managing memory in a kernel-mode environment. They also discuss alternative approaches to Windows driver development, such as using frameworks like the Windows Driver Framework (WDF).

• ROCm Device Support Wishlist

  permalink

  Posted: 2025-01-20 19:31:03

  Verbose tl;dr

  The ROCm Device Support Wishlist GitHub discussion serves as a central hub for users to request and discuss support for new AMD GPUs and other hardware within the ROCm platform. It encourages users to upvote existing requests or submit new ones with detailed system information, emphasizing driver versions and specific models for clarity and to gauge community interest. The goal is to provide the ROCm developers with a clear picture of user demand, helping them prioritize development efforts for broader hardware compatibility.

  The GitHub Discussion post titled "ROCm Device Support Wishlist" serves as a centralized location for the ROCm community to express their desires for expanded GPU hardware support within the ROCm software ecosystem. The post's author recognizes the frequent inquiries regarding support for specific GPUs, particularly older models and those from other vendors like NVIDIA and Intel. Instead of scattering these requests across various forums and issue trackers, the discussion thread aims to consolidate them into a single, easily accessible list. This organized approach allows the ROCm developers to better gauge community interest and prioritize their efforts accordingly. The author explicitly encourages users to contribute by adding their desired GPUs to the list, emphasizing the importance of including the specific model name for clarity. This collaborative wishlist intends to streamline communication and provide valuable feedback to the ROCm development team, ultimately helping shape the future of ROCm hardware compatibility. While acknowledging that adding support for a particular GPU is a complex undertaking dependent on various factors, the wishlist provides a valuable mechanism for understanding community needs and guiding development decisions. The post itself doesn't guarantee support for any listed GPU, but rather establishes a formal channel for expressing and tracking community demand for broader hardware compatibility.

  • ROCm
  • GPU
  • AMD
  • Device Support
  • Wishlist
  • Hardware
  • Software
  • Open Source
  • Compute
  • GPGPU
  • HIP
  • Driver
  • Kernel
  • Radeon
  • Graphics Card

  Summary of Comments ( 75 )
  https://news.ycombinator.com/item?id=42772170

  Verbose tl;dr

  Hacker News users discussed the ROCm device support wishlist, expressing both excitement and skepticism. Some were enthusiastic about the potential for wider AMD GPU adoption, particularly for scientific computing and AI workloads where open-source solutions are preferred. Others questioned the viability of ROCm competing with CUDA, citing concerns about software maturity, performance consistency, and developer mindshare. The need for more robust documentation and easier installation processes was a recurring theme. Several commenters shared personal experiences with ROCm, highlighting successes with specific applications but also acknowledging difficulties in getting it to work reliably across different hardware configurations. Some expressed hope for better support from AMD to broaden adoption and improve the overall ROCm ecosystem.

  The Hacker News post "ROCm Device Support Wishlist" (https://news.ycombinator.com/item?id=42772170) links to a GitHub discussion where users can express their desire for ROCm support on various devices. The discussion on Hacker News itself is relatively short, with a limited number of comments focusing on a few key areas.

  One commenter expresses excitement about the potential for wider ROCm support, specifically mentioning older Radeon HD 7000 series GPUs. They highlight the value these cards could still provide for compute tasks if ROCm were available, potentially extending their useful life and providing a cost-effective option for users. This comment emphasizes the desire for broader hardware support to unlock the potential of older, but still capable, hardware.

  Another commenter raises a practical consideration regarding driver support and kernel compatibility. They point out that older GPUs often face challenges with newer kernels, questioning whether these older cards would even function with a contemporary kernel required by ROCm. This introduces the complexity of balancing support for older hardware with the requirements of a modern software stack. It highlights the potential difficulties in bringing ROCm to older architectures, even if there is user demand.

  A further comment shifts the focus to the professional compute market, noting the prevalence of NVIDIA in that space. They speculate on the reasons behind AMD's focus and suggest that perhaps AMD is prioritizing the professional market over consumer or prosumer needs with ROCm. This comment brings in the broader context of the GPU market and competitive landscape, suggesting that AMD's strategic decisions might be influencing their support priorities for ROCm.

  The remaining comments are brief and less substantive. One simply expresses a desire for broader ROCm support without specifying particular hardware. Another provides a link to a ROCm compatibility chart.

  In summary, the Hacker News discussion, while concise, touches on the desire for wider ROCm support, particularly for older hardware, while also acknowledging the technical challenges and strategic considerations that might influence AMD's decisions in this area. The discussion doesn't delve deeply into any particular area but provides a glimpse into user interest and the practicalities of expanding ROCm compatibility.