include/uapi/rdma/ib_user_mad.h
Source file repositories/reference/linux-study-clean/include/uapi/rdma/ib_user_mad.h
File Facts
- System
- Linux kernel
- Corpus path
include/uapi/rdma/ib_user_mad.h- Extension
.h- Size
- 8530 bytes
- Lines
- 235
- Domain
- Repository Root And Misc
- Bucket
- include
- Inferred role
- Repository Root And Misc: implementation source
- Status
- source implementation candidate
Why This File Exists
Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Top-level or miscellaneous repository surface. Use this as map coverage unless a later manual pass promotes the file into a deeper subsystem dossier.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hrdma/rdma_user_ioctl.h
Detected Declarations
struct ib_user_mad_hdr_oldstruct ib_user_mad_hdrstruct ib_user_madstruct ib_user_mad_reg_reqstruct ib_user_mad_reg_req2
Annotated Snippet
struct ib_user_mad_hdr_old {
__u32 id;
__u32 status;
__u32 timeout_ms;
__u32 retries;
__u32 length;
__be32 qpn;
__be32 qkey;
__be16 lid;
__u8 sl;
__u8 path_bits;
__u8 grh_present;
__u8 gid_index;
__u8 hop_limit;
__u8 traffic_class;
__u8 gid[16];
__be32 flow_label;
};
/**
* ib_user_mad_hdr - MAD packet header
* This layout allows specifying/receiving the P_Key index. To use
* this capability, an application must call the
* IB_USER_MAD_ENABLE_PKEY ioctl on the user MAD file handle before
* any other actions with the file handle.
* @id - ID of agent MAD received with/to be sent with
* @status - 0 on successful receive, ETIMEDOUT if no response
* received (transaction ID in data[] will be set to TID of original
* request) (ignored on send)
* @timeout_ms - Milliseconds to wait for response (unset on receive)
* @retries - Number of automatic retries to attempt
* @qpn - Remote QP number received from/to be sent to
* @qkey - Remote Q_Key to be sent with (unset on receive)
* @lid - Remote lid received from/to be sent to
* @sl - Service level received with/to be sent with
* @path_bits - Local path bits received with/to be sent with
* @grh_present - If set, GRH was received/should be sent
* @gid_index - Local GID index to send with (unset on receive)
* @hop_limit - Hop limit in GRH
* @traffic_class - Traffic class in GRH
* @gid - Remote GID in GRH
* @flow_label - Flow label in GRH
* @pkey_index - P_Key index
*/
struct ib_user_mad_hdr {
__u32 id;
__u32 status;
__u32 timeout_ms;
__u32 retries;
__u32 length;
__be32 qpn;
__be32 qkey;
__be16 lid;
__u8 sl;
__u8 path_bits;
__u8 grh_present;
__u8 gid_index;
__u8 hop_limit;
__u8 traffic_class;
__u8 gid[16];
__be32 flow_label;
__u16 pkey_index;
__u8 reserved[6];
};
/**
* ib_user_mad - MAD packet
* @hdr - MAD packet header
* @data - Contents of MAD
*
*/
struct ib_user_mad {
struct ib_user_mad_hdr hdr;
__aligned_u64 data[];
};
/*
* Earlier versions of this interface definition declared the
* method_mask[] member as an array of __u32 but treated it as a
* bitmap made up of longs in the kernel. This ambiguity meant that
* 32-bit big-endian applications that can run on both 32-bit and
* 64-bit kernels had no consistent ABI to rely on, and 64-bit
* big-endian applications that treated method_mask as being made up
* of 32-bit words would have their bitmap misinterpreted.
*
* To clear up this confusion, we change the declaration of
* method_mask[] to use unsigned long and handle the conversion from
* 32-bit userspace to 64-bit kernel for big-endian systems in the
* compat_ioctl method. Unfortunately, to keep the structure layout
* the same, we need the method_mask[] array to be aligned only to 4
Annotation
- Immediate include surface: `linux/types.h`, `rdma/rdma_user_ioctl.h`.
- Detected declarations: `struct ib_user_mad_hdr_old`, `struct ib_user_mad_hdr`, `struct ib_user_mad`, `struct ib_user_mad_reg_req`, `struct ib_user_mad_reg_req2`.
- Atlas domain: Repository Root And Misc / include.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.