STRUCT MPT3_DIAG_READ_BUFFER(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay so bestie, welcome to the struct mpt3_diag_read_buffer page from the Kernel API Manual ✨ this little cutie is literally a request for copy of the diag buffer. The og NAME block is giving β€œgroup chat where everyone talks at once,” so here’s the field-by-field breakdown, no cap:

  • struct mpt3_diag_read_buffer β€” request for copy of the diag buffer
  • @hdr β€” generic header
  • @status β€” the original doesn’t give an extra description here, bestie
  • @reserved β€” same vibe, no extra description in the original
  • @flags β€” misc flags
  • @starting_offset β€” starting offset within drivers buffer where to start reading data at into the specified application buffer
  • @bytes_to_read β€” number of bytes to copy from the drivers buffer into the application buffer starting at starting_offset.
  • @unique_id β€” unique id associated with this buffer.
  • @diagnostic_data β€” data payload

✨ SYNOPSIS ✨

here’s the struct in all its glory, copied exactly because we do not play with code around here πŸ’…

       struct mpt3_diag_read_buffer {
           struct mpt3_ioctl_header hdr;
           uint8_t status;
           uint8_t reserved;
           uint16_t flags;
           uint32_t starting_offset;
           uint32_t bytes_to_read;
           uint32_t unique_id;
           uint32_t diagnostic_data[1];
        };

🌸 Members 🌸

the og page has a Members heading and then basically nothing β€” iconic, honestly. The members are the fields in the struct, and the descriptions are the same deets from NAME above. Here’s the type lineup from the synopsis so you can match names to types:

  • struct mpt3_ioctl_header hdr β€” generic header
  • uint8_t status β€” no extra description in the original
  • uint8_t reserved β€” no extra description in the original
  • uint16_t flags β€” misc flags
  • uint32_t starting_offset β€” starting offset within drivers buffer where to start reading data at into the specified application buffer
  • uint32_t bytes_to_read β€” number of bytes to copy from the drivers buffer into the application buffer starting at starting_offset
  • uint32_t unique_id β€” unique id associated with this buffer
  • uint32_t diagnostic_data[1] β€” data payload

πŸ¦‹ SEE ALSO πŸ¦‹

okay bestie, if you wanna fall down the rabbit hole, these are the related pages and the kernel file, all names exactly as the og page gives them:

  • Kernel file ./drivers/scsi/mpt3sas/mpt3sas_ctl.h
  • struct mpt3_ioctl_header(9)
  • struct mpt3_ioctl_diag_reset(9)
  • struct mpt3_ioctl_pci_info(9)
  • struct mpt3_ioctl_iocinfo(9)
  • struct mpt3_ioctl_eventquery(9)
  • struct mpt3_ioctl_eventenable(9)
  • struct MPT3_IOCTL_EVENTS(9)
  • struct mpt3_ioctl_eventreport(9)
  • struct mpt3_ioctl_command(9)
  • struct mpt3_ioctl_btdh_mapping(9)
  • struct mpt3_diag_register(9)
  • struct mpt3_diag_unregister(9)
  • struct mpt3_diag_query(9)
  • struct mpt3_diag_release(9)
  • struct mpt3_addnl_diag_query(9)
  • struct mpt3_enable_diag_sbr_reload(9)
  • struct mpt3_passthru_command(9)

mwah πŸ’‹ β€” this cutie lives in the source/version ./drivers/scsi/mpt3sas, dated October 2026, and the page is struct mpt3_..._read_buffer(9). slay ✨

πŸ“¦ where this page comes from