STRUCT CXL_SEND_COMMAND(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct cxl_send_command(9) β€” bestie edition πŸ’–

okay so this is a page straight out of the Kernel API Manual, and it's literally the blueprint for yeeting a command at a memory device. no cap, it's giving "userspace talks to hardware" and honestly? iconic. let's get into it 🫢


✨ NAME ✨

struct cxl_send_command β€” Send a command to a memory device.</p> that's it, that's the whole vibe. πŸŽ€


🌸 SYNOPSIS 🌸

here's the struct in all her glory, character for character, don't touch a single brace bestie:

struct cxl_send_command {
    __u32 id;
    __u32 flags;
    union {
      struct {
        __u16 opcode;
        __u16 rsvd;
      } raw;
      __u32 rsvd;
    };
    __u32 retval;
    struct {
      __u32 size;
      __u32 rsvd;
      __u64 payload;
    } in;
    struct {
      __u32 size;
      __u32 rsvd;
      __u64 payload;
    } out;
 };

πŸ¦‹ Members πŸ¦‹

time for the member-by-member tour, lowkey my favorite part πŸ’…

  • id β€” the command you're sending to the memory device. and like, it must be one of the commands that the query command returned. no making up your own ids, bestie, that's not the move. πŸ™ˆ
  • flags β€” flags for the command (input). 🚩
  • {unnamed_union} β€” anonymous. she has no name but she's still main character energy. πŸ’€
  • raw β€” special fields for raw commands. the ✨raw✨ girlies.
  • raw.opcode β€” the opcode passed to hardware when you're using the RAW command. very direct, very "i'll handle it myself". πŸ”₯
  • raw.rsvd β€” must be zero. not optional, not a suggestion. zero. periodt.
  • rsvd β€” must be zero. yeah, same. zero it out. ⭐
  • retval β€” return value from the memory device (output). the device's lil text-back, if you will. πŸ“¬
  • in β€” parameters associated with input payload. what you're feeding her. πŸ“
  • in.size β€” size of the payload to provide to the device (input). πŸ“
  • in.rsvd β€” must be zero. (yes, again. i know. but rules are rules.) πŸ’œ
  • in.payload β€” pointer to memory for payload input, and the payload is little endian. pointers and endianness, the classic combo. 🧚
  • out β€” parameters associated with output payload. what she's giving back to you. 🌈
  • out.size β€” size of the payload received from the device (input/output). okay this one's a two-way street: userspace fills this in to let the driver know how much space was allocated for output, and then it gets populated by the driver to let userspace know how large the output payload actually was. she's doing double duty and she's slaying it. πŸ‘‘
  • out.rsvd β€” must be zero. one more time for the people in the back. πŸ’€
  • out.payload β€” pointer to memory for payload output, payload is little endian. same endian energy as in.payload, we love consistency. πŸŽ€

πŸ’… Description πŸ’…

so this whole struct is the mechanism for userspace to send a command to the hardware for processing. that's the entire point. 🎯

the driver will do basic validation on the command sizes β€” key word basic, so don't get cocky. in some cases even the payload may be introspected. πŸ‘€

⚠️ bestie listen: userspace is required to allocate large enough buffers for size_out, which can be variable length in certain situations. variable length means you can't just eyeball it. allocate generously or perish. 😭

πŸ” SEE ALSO πŸ”

go read these next, fr fr:

  • Kernel file ./include/uapi/linux/cxl_mem.h UAPI(9)
  • struct cxl_command_info(9)
  • struct cxl_mem_query_commands(9)

and that's the whole page, bestie!! πŸ₯³ this absolute icon lives in ./include/uapi/linux, dated October 2026, and she slays every day. mwah πŸ’‹ bye bestie, go zero those rsvd fields!! πŸ¦‹βœ¨

πŸ“¦ where this page comes from