include/uapi/linux/sync_file.h
Source file repositories/reference/linux-study-clean/include/uapi/linux/sync_file.h
File Facts
- System
- Linux kernel
- Corpus path
include/uapi/linux/sync_file.h- Extension
.h- Size
- 3464 bytes
- Lines
- 114
- 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/ioctl.hlinux/types.h
Detected Declarations
struct sync_merge_datastruct sync_fence_infostruct sync_file_infostruct sync_set_deadline
Annotated Snippet
struct sync_merge_data {
char name[32];
__s32 fd2;
__s32 fence;
__u32 flags;
__u32 pad;
};
/**
* struct sync_fence_info - detailed fence information
* @obj_name: name of parent sync_timeline
* @driver_name: name of driver implementing the parent
* @status: status of the fence 0:active 1:signaled <0:error
* @flags: fence_info flags
* @timestamp_ns: timestamp of status change in nanoseconds
*/
struct sync_fence_info {
char obj_name[32];
char driver_name[32];
__s32 status;
__u32 flags;
__u64 timestamp_ns;
};
/**
* struct sync_file_info - SYNC_IOC_FILE_INFO: get detailed information on a sync_file
* @name: name of fence
* @status: status of fence. 1: signaled 0:active <0:error
* @flags: sync_file_info flags
* @num_fences: number of fences in the sync_file
* @pad: padding for 64-bit alignment, should always be zero
* @sync_fence_info: pointer to array of struct &sync_fence_info with all
* fences in the sync_file
*
* Takes a struct sync_file_info. If num_fences is 0, the field is updated
* with the actual number of fences. If num_fences is > 0, the system will
* use the pointer provided on sync_fence_info to return up to num_fences of
* struct sync_fence_info, with detailed fence information.
*/
struct sync_file_info {
char name[32];
__s32 status;
__u32 flags;
__u32 num_fences;
__u32 pad;
__u64 sync_fence_info;
};
/**
* struct sync_set_deadline - SYNC_IOC_SET_DEADLINE - set a deadline hint on a fence
* @deadline_ns: absolute time of the deadline
* @pad: must be zero
*
* Allows userspace to set a deadline on a fence, see &dma_fence_set_deadline
*
* The timebase for the deadline is CLOCK_MONOTONIC (same as vblank). For
* example
*
* clock_gettime(CLOCK_MONOTONIC, &t);
* deadline_ns = (t.tv_sec * 1000000000L) + t.tv_nsec + ns_until_deadline
*/
struct sync_set_deadline {
__u64 deadline_ns;
/* Not strictly needed for alignment but gives some possibility
* for future extension:
*/
__u64 pad;
};
#define SYNC_IOC_MAGIC '>'
/*
* Opcodes 0, 1 and 2 were burned during a API change to avoid users of the
* old API to get weird errors when trying to handling sync_files. The API
* change happened during the de-stage of the Sync Framework when there was
* no upstream users available.
*/
#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline)
#endif /* _UAPI_LINUX_SYNC_H */
Annotation
- Immediate include surface: `linux/ioctl.h`, `linux/types.h`.
- Detected declarations: `struct sync_merge_data`, `struct sync_fence_info`, `struct sync_file_info`, `struct sync_set_deadline`.
- 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.