Re: [akpm-mm:mm-new 36/102] error[E0425]: cannot find value `VM_READ` in crate `bindings`

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Fri, Oct 10, 2025 at 8:07 AM Jakub Acs <acsjakub@amazon.de> wrote:
>
> FWIW Alice suggested the enum version and we discussed adjustment to the
> patch in thread [1]. I was going to send new version of the patch as
> soon as I figure out how to test for the issue pointed out by Derrick in
> [2].
>
> Please let me know if that is desired or whether you're taking care of
> it here. And/or how else I can help.

The `enum` approach is what we usually suggest if possible, and in
this case it also avoids having to replicate conditional compilation
on the Rust side, which is good.

However, using it here as-is means the resulting type of
`VM_MERGEABLE` is `unsigned int`, not `unsigned long` -- but wasn't
that an issue? i.e.

    https://lore.kernel.org/all/20250930130023.60106-1-acsjakub@amazon.de/

We may be able to use a dummy larger constant to force the compiler to
pick a bigger underlying type, e.g. something like:

    __VM_FLAGS_FORCE_UL    = BIT(63),

But note that older versions of GCC and Clang keep the smaller `enum`
constants as `int` (i.e. small and signed), even if they will pick
`unsigned long` for the bigger ones. Newer versions will pick
`unsigned long` for all.

The best would be to use C23-like `enum : unsigned long { ... }`, but
sadly we don't have a recent enough GCC as a minimum in the kernel
(GCC 13).

If there are extra complications with the `enum` approach (i.e. second
link), then perhaps just replicating it on the Rust side is simpler.

Cheers,
Miguel