include/uapi/linux/dm-ioctl.h
Source file repositories/reference/linux-study-clean/include/uapi/linux/dm-ioctl.h
File Facts
- System
- Linux kernel
- Corpus path
include/uapi/linux/dm-ioctl.h- Extension
.h- Size
- 11749 bytes
- Lines
- 391
- Domain
- Core OS
- Bucket
- Core Kernel Interface
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.h
Detected Declarations
struct dm_ioctlstruct dm_target_specstruct dm_target_depsstruct dm_name_liststruct dm_target_versionsstruct dm_target_msg
Annotated Snippet
struct dm_ioctl {
/*
* The version number is made up of three parts:
* major - no backward or forward compatibility,
* minor - only backwards compatible,
* patch - both backwards and forwards compatible.
*
* All clients of the ioctl interface should fill in the
* version number of the interface that they were
* compiled with.
*
* All recognised ioctl commands (ie. those that don't
* return -ENOTTY) fill out this field, even if the
* command failed.
*/
__u32 version[3]; /* in/out */
__u32 data_size; /* total size of data passed in
* including this struct */
__u32 data_start; /* offset to start of data
* relative to start of this struct */
__u32 target_count; /* in/out */
__s32 open_count; /* out */
__u32 flags; /* in/out */
/*
* event_nr holds either the event number (input and output) or the
* udev cookie value (input only).
* The DM_DEV_WAIT ioctl takes an event number as input.
* The DM_SUSPEND, DM_DEV_REMOVE and DM_DEV_RENAME ioctls
* use the field as a cookie to return in the DM_COOKIE
* variable with the uevents they issue.
* For output, the ioctls return the event number, not the cookie.
*/
__u32 event_nr; /* in/out */
__u32 padding;
__u64 dev; /* in/out */
char name[DM_NAME_LEN]; /* device name */
char uuid[DM_UUID_LEN]; /* unique identifier for
* the block device */
char data[7]; /* padding or data */
};
/*
* Used to specify tables. These structures appear after the
* dm_ioctl.
*/
struct dm_target_spec {
__u64 sector_start;
__u64 length;
__s32 status; /* used when reading from kernel only */
/*
* Location of the next dm_target_spec.
* - When specifying targets on a DM_TABLE_LOAD command, this value is
* the number of bytes from the start of the "current" dm_target_spec
* to the start of the "next" dm_target_spec.
* - When retrieving targets on a DM_TABLE_STATUS command, this value
* is the number of bytes from the start of the first dm_target_spec
* (that follows the dm_ioctl struct) to the start of the "next"
* dm_target_spec.
*/
__u32 next;
char target_type[DM_MAX_TYPE_NAME];
/*
* Parameter string starts immediately after this object.
* Be careful to add padding after string to ensure correct
* alignment of subsequent dm_target_spec.
*/
};
/*
* Used to retrieve the target dependencies.
*/
struct dm_target_deps {
__u32 count; /* Array size */
__u32 padding; /* unused */
__u64 dev[]; /* out */
};
/*
* Used to get a list of all dm devices.
*/
struct dm_name_list {
__u64 dev;
Annotation
- Immediate include surface: `linux/types.h`.
- Detected declarations: `struct dm_ioctl`, `struct dm_target_spec`, `struct dm_target_deps`, `struct dm_name_list`, `struct dm_target_versions`, `struct dm_target_msg`.
- Atlas domain: Core OS / Core Kernel Interface.
- 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.