net/rds/rdma_transport.h
Source file repositories/reference/linux-study-clean/net/rds/rdma_transport.h
File Facts
- System
- Linux kernel
- Corpus path
net/rds/rdma_transport.h- Extension
.h- Size
- 860 bytes
- Lines
- 31
- Domain
- Networking Core
- Bucket
- Sockets, Protocols, Packet Path, And Network Policy
- Inferred role
- Networking Core: implementation source
- Status
- source implementation candidate
Why This File Exists
Networking stack implementation surface: socket APIs, protocol dispatch, packet flow, routing, filtering, and network namespaces.
- Networking stack implementation surface: socket APIs, protocol dispatch, packet flow, routing, filtering, and network namespaces.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
rdma/ib_verbs.hrdma/rdma_cm.hrds.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef _RDMA_TRANSPORT_H
#define _RDMA_TRANSPORT_H
#include <rdma/ib_verbs.h>
#include <rdma/rdma_cm.h>
#include "rds.h"
/* RDMA_CM also uses 16385 as the listener port. */
#define RDS_CM_PORT 16385
#define RDS_RDMA_RESOLVE_TIMEOUT_MS 5000
/* Below reject reason is for legacy interoperability issue with non-linux
* RDS endpoints where older version incompatibility is conveyed via value 1.
* For future version(s), proper encoded reject reason should be used.
*/
#define RDS_RDMA_REJ_INCOMPAT 1
int rds_rdma_cm_event_handler(struct rdma_cm_id *cm_id,
struct rdma_cm_event *event);
int rds6_rdma_cm_event_handler(struct rdma_cm_id *cm_id,
struct rdma_cm_event *event);
/* from ib.c */
extern struct rds_transport rds_ib_transport;
int rds_ib_init(void);
void rds_ib_exit(void);
#endif
Annotation
- Immediate include surface: `rdma/ib_verbs.h`, `rdma/rdma_cm.h`, `rds.h`.
- Atlas domain: Networking Core / Sockets, Protocols, Packet Path, And Network Policy.
- 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.