Re: [PATCH v11 4/4] rust: gpu: Add GPU buddy allocator bindings

["Alexandre Courbot" <acourbot@nvidia.com>]

On Fri Feb 27, 2026 at 6:42 AM JST, Joel Fernandes wrote:
<snip>
>> 
>> And the job of `alloc_blocks` is also simplified:
>> 
>>     let (start, end) = match mode {
>>         GpuBuddyAllocMode::Range { start, end } => (start, end),
>>         _ => (0, 0),
>>     };
>>     let flags = mode.into_flags() | u32::from(flags) as usize;
>>     // ... and just invoke the C API with these parameters.
>> 
>>> if the C allocator evolves its flag semantics (new combinations become
>>> valid, or existing constraints change), an enum on the Rust side would
>>> break. It's simpler and more maintainable to pass combinable flags and
>>> let the C allocator validate -- which it already does. The switch to
>>> `impl_flags!` will work for us without over-constraining.
>> 
>> The evolution you describe is speculative and unlikely to happen as it
>> would break all C users just the same. And if the C API adds new flags
>> or allocation modes, we will have to update the Rust abstraction either
>> way.
>
> How/why would it break C users? Currently top down + range is silently ignored,
> implementing it is unlikely to break them.
>
> I also wouldn't call it speculative: top-down within a range is a natural
> feature the C allocator could add right? By modeling modes as a mutually
> exclusive enum, we're disallowing a flag combination that could become
> valid in the future. That's fine for now, but something to keep in mind as we
> choose this design. We could add a new RangeTopDown mode variant in the future,
> though. That said, I've made the switch to the enum as
> you suggested since it is cleaner code! And is more Rust-like as you pointed.

Ah, I thought you were talking about new flags - the case you are
quoting is different, and indeed more concerning. I guess if things were
to change in that direction we would have to move top-down into its own
flag and update our users. But for now we should try to support the
existing actual semantics as closely as possible, and without any
surprise if possible - what you get is exactly what you get, without
anything swept under the rug (the silent masking done on the C side
freaks me out a little bit tbh ^_^;).

Should top-down become a flag, our current API also wouldn't become
incorrect - it would just be incomplete in that it doesn't support the
new use-case until we update it, so thankfully that wouldn't be a
critical issue.