BITMAP_FROM_U64(9)

📦 version 7.3.1, in nixpkgs unstable

💅 BITMAP_FROM_U64(9) — the Kernel API Manual, bestie edition 🎀

Okay so this one is from the Kernel API Manual and it's literally about representing a u64 value in a format that's suitable for a bitmap. It's giving "tiny macro, big endian energy" and I'm obsessed. Let's get into it ✨

✨ NAME ✨

BITMAP_FROM_U64 — Represent u64 value in the format suitable for bitmap. That's it, that's the whole gig 🫶

🌸 SYNOPSIS 🌸

BITMAP_FROM_U64 (n );

Yes bestie, that's the whole call. One argument and a dream 💖

🦋 ARGUMENTS 🦋

  • n — a u64 value. That's the number you're feeding in, no cap 🔥

👑 DESCRIPTION 👑

Okay so first things first, you gotta understand what a Linux bitmap actually is on the inside, because it's not what you'd assume 💀

Linux bitmaps are internally arrays of unsigned longs, i.e. 32-bit integers in a 32-bit environment, and 64-bit integers in a 64-bit one. So the size of each little word totally depends on where you're running. Iconic, honestly.

There are four combinations of endianness and length of the word in linux ABIs, and they are:

  • LE64
  • BE64
  • LE32
  • BE32

Four icons. One vibe check. 🌈

🌟 the 64-bit girlies 🌟

On 64-bit kernels, 64-bit LE and BE numbers are naturally ordered in bitmaps and therefore don't require any special handling. Like, they're just born correct. Main character energy from birth 👑✨

🎀 the 32-bit situation (this is where it gets spicy) 🎀

On 32-bit kernels, the 32-bit LE ABI orders the lo word of a 64-bit number in memory prior to hi, and 32-bit BE orders hi word prior to lo. So the two endians literally cannot agree on word order. Classic 🙈

The bitmap, on the other hand, is represented as an array of 32-bit words, and the position of bit N may therefore be calculated as: word #(N/32) and bit #(N32) in that word. (Yes, that's exactly how it's written, bestie — copying it character for character, don't come for me 💅)

For example, bit #42 is located at 10th position of 2nd word. Cute, right? 🍓

That matches the 32-bit LE ABI, and we can simply let the compiler store 64-bit values in memory as it usually does. But for BE we need to swap hi and lo words manually. So it's not free, it's just correct 😭

💜 and that's the whole reason this macro exists 💜

With all that, the macro BITMAP_FROM_U64 does explicit reordering of hi and lo parts of u64.

  • For LE32 it does nothing — literally nothing, a whole no-op, and that's slay ✨
  • For BE environment it swaps the hi and lo words, as is expected by bitmap.

So it's a tiny little endianness bouncer at the door of your bitmap. Doorman behavior, but make it kernel 🫶🔥

Heads up: don't be out here assuming it does something on LE32. It does nothing. That's the whole point. The reordering only happens when the BE environment needs it. 💀

🧚 SEE ALSO 🧚

Kernel file ./include/linux/bitmap.h plus the whole bestie lineup, in this exact order, and yes I'm listing all of them because we do not skip the boring parts in this house 💅💖

And that's the page! 🌸 Big sign-off energy: this one lives in ./include/linux, it's dated October 2026, and honestly? She ate. Periodt. 💅🎀✨

📦 where this page comes from