On Fri Oct 31, 2025 at 4:06 AM JST, Joel Fernandes wrote:
<snip>
> + /// Allocate blocks from the buddy allocator.
> + ///
> + /// Returns an [`AllocatedBlocks`] structure that owns the allocated
> blocks and automatically
> + /// frees them when dropped. Allocation of `list_head` uses the `gfp`
> flags passed.
> + pub fn alloc_blocks(
> + &self,
> + start: usize,
> + end: usize,
> + size: usize,
> + min_block_size: usize,
> + flags: BuddyFlags,
> + gfp: Flags,
> + ) -> Result<AllocatedBlocks<'_>> {
It looks like some of the flags heavily modify the behavior of the
allocator, and make some of the parameters irrelevant (for instance,
IIUC `start` and `end` only make sense if `RANGE_ALLOCATION` is
passed?).
In that case, we should either have several allocation methods, or have
an `AllocationRequest` enum which variants are the allocation type and its
relevant parameters. E.g (very naively):
enum AllocationRange {
Whole,
Ranged(Range<u64>),
...
}
struct AllocationRequest {
range: AllocationRange,
top_down: bool,
contiguous: bool,
clear: bool,
}
I.e. use the type system to make sure we can only express things that
make sense, and never pass data that will end up being ignored.
If we do that well, I think we can drop the `BuddyFlags` type
altogether, which is great as it seems to serve several different
purposes.
