Re: [PATCH 0/3] rust_binder: Update bitmaps to use kernel::impl_flags!
Alice Ryhl <[email protected]>
| Newsgroups | org.kernel.vger.rust-for-linux,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jul 16, 2026 at 01:02:33PM +0000, Jahnavi MN via B4 Relay wrote: > In the current Rust Binder driver, internal state variables (thread > looper states, deferred work, and transaction configurations) are > represented as raw integers and manipulated using manual bitwise > operations. > > This approach lacks type safety. Because the compiler treats all > integers identically, it is possible to pass a thread looper flag > into a function expecting a transaction flag without triggering > compile-time warnings. These cross-contamination errors compile > cleanly but can cause runtime bugs or undefined behavior. > > This patch series resolves this issue by migrating these raw integer > bitmaps (`defer_work`, `looper_flags`, `flags`) to strongly-typed > bitmasks using the `kernel::impl_flags!` macro. Functions now accept > specific, distinct types rather than generic integers, preventing > flags from being mixed up. This transition also replaces manual > bitwise arithmetic with readable, safe methods. > > Based on top of: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > > Signed-off-by: Jahnavi MN <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> It would be nice if our impl_flags! macro could allow us to omit the right-hand-side that's saying `= bit_u8(i)` here: /// Represents a single deferred work category. #[derive(Debug, Clone, Copy, PartialEq, Eq)] pub enum DeferWork { Flush = bit_u8(0), Release = bit_u8(1), } After all, if we don't care what values the bits take, the macro could just assign them for us. Alice