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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.