Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
From:   Miguel Ojeda <ojeda@kernel.org>
To:     gregkh@linuxfoundation.org
Cc:     aliceryhl@google.com, arve@android.com, christian@brauner.io,
        cmllamas@google.com, dualli@google.com, joel@joelfernandes.org,
        kernel-team@android.com, linux-kernel@vger.kernel.org,
        maco@android.com, rust-for-linux@vger.kernel.org,
        surenb@google.com, tkjos@android.com, jbaublitz@redhat.com,
        aaron@aaronballman.com, emilio@crisal.io,
        christian.poveda@ferrous-systems.com,
        Miguel Ojeda <ojeda@kernel.org>
Subject: Re: [PATCH] binder: use enum for binder ioctls
Date:   Sat,  9 Dec 2023 22:05:44 +0100
Message-ID: <20231209210544.139181-1-ojeda@kernel.org>
In-Reply-To: <2023120936-decency-engraved-5346@gregkh>
References: <2023120936-decency-engraved-5346@gregkh>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

> Does this mean that we will have to wrap every ioctl definition in an
> enum just to get access to it in rust code?

Currently, yes (or one can build them on the Rust side using the `_IO*` const
functions that are in mainline at `rust/kernel/ioctl.rs`).

> What makes these defines so magical that bindgen can't decode them?  Is
> it just the complexity of the C preprocessor logic involved?  Any plans
> for bindgen to resolve this?

Yeah, currently bindgen only resolves "trivial" object-like macros. As soon as
a macro is more complex it does not work, even if it would still resolve into
a constant. The upstream issue for this particular case (a macro that uses
other function-like macros) uses `_IO*`s as the example, in fact, and is at:

    https://github.com/rust-lang/rust-bindgen/issues/753

which we track in our bindgen list at:

    https://github.com/Rust-for-Linux/linux/issues/353

There are several ways forward for bindgen here. Ideally, libclang would give
the resolved value to bindgen. This may require changes in upstream Clang.
I contacted Aaron Ballman (the Clang maintainer, Cc'd) a while ago and
he kindly offered to review the changes if they were eventually needed.

Otherwise (or meanwhile), it is also possible to implement a workaround that
stores the information in a way that can be retrieved by bindgen by using
the macro in some way (e.g. initializing a variable and asking for the value
of the variable). It is ugly, but it should work (at least for many cases --
there may be other compounding issues with e.g. 128-bit integers).

John Baublitz (Cc'd) has spent some time on this and, from what I can tell from
the issue, we may be waiting on an answer from bindgen (Cc'ing Emilio and
Christian, the bindgen maintainers) on whether the workaround is OK for them.
The workaround would be nice to have even if we change upstream Clang, because
it would help in many cases we care about, without having to wait until we get
a new LLVM released and so on.

Hope that helps!

Cheers,
Miguel