include/linux/uio.h
Source file repositories/reference/linux-study-clean/include/linux/uio.h
File Facts
- System
- Linux kernel
- Corpus path
include/linux/uio.h- Extension
.h- Size
- 12401 bytes
- Lines
- 423
- 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.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/kernel.hlinux/mm_types.hlinux/ucopysize.huapi/linux/uio.h
Detected Declarations
struct pagestruct folio_queuestruct kvecstruct iov_iter_statestruct iov_iterstruct uio_metastruct sg_tableenum iter_typefunction iter_iov_lenfunction iov_iter_typefunction iov_iter_save_statefunction iter_is_ubuffunction iter_is_iovecfunction iov_iter_is_kvecfunction iov_iter_is_bvecfunction iov_iter_is_discardfunction iov_iter_is_folioqfunction iov_iter_is_xarrayfunction iov_iter_rwfunction user_backed_iterfunction iov_lengthfunction copy_folio_to_iterfunction copy_folio_from_iterfunction copy_to_iterfunction copy_from_iterfunction copy_to_iter_fullfunction copy_from_iter_fullfunction copy_from_iter_nocachefunction copy_from_iter_full_nocachefunction iov_iter_countfunction iov_iter_truncatefunction iov_iter_reexpandfunction iov_iter_npages_capfunction iov_iter_ubuffunction child
Annotated Snippet
struct kvec {
void *iov_base; /* and that should *never* hold a userland pointer */
size_t iov_len;
};
enum iter_type {
/* iter types */
ITER_UBUF,
ITER_IOVEC,
ITER_BVEC,
ITER_KVEC,
ITER_FOLIOQ,
ITER_XARRAY,
ITER_DISCARD,
};
#define ITER_SOURCE 1 // == WRITE
#define ITER_DEST 0 // == READ
struct iov_iter_state {
size_t iov_offset;
size_t count;
unsigned long nr_segs;
};
struct iov_iter {
u8 iter_type;
bool nofault;
bool data_source;
size_t iov_offset;
/*
* Hack alert: overlay ubuf_iovec with iovec + count, so
* that the members resolve correctly regardless of the type
* of iterator used. This means that you can use:
*
* &iter->__ubuf_iovec or iter->__iov
*
* interchangably for the user_backed cases, hence simplifying
* some of the cases that need to deal with both.
*/
union {
/*
* This really should be a const, but we cannot do that without
* also modifying any of the zero-filling iter init functions.
* Leave it non-const for now, but it should be treated as such.
*/
struct iovec __ubuf_iovec;
struct {
union {
/* use iter_iov() to get the current vec */
const struct iovec *__iov;
const struct kvec *kvec;
const struct bio_vec *bvec;
const struct folio_queue *folioq;
struct xarray *xarray;
void __user *ubuf;
};
size_t count;
};
};
union {
unsigned long nr_segs;
u8 folioq_slot;
loff_t xarray_start;
};
};
typedef __u16 uio_meta_flags_t;
struct uio_meta {
uio_meta_flags_t flags;
u16 app_tag;
u64 seed;
struct iov_iter iter;
};
static inline const struct iovec *iter_iov(const struct iov_iter *iter)
{
if (iter->iter_type == ITER_UBUF)
return (const struct iovec *) &iter->__ubuf_iovec;
return iter->__iov;
}
#define iter_iov_addr(iter) (iter_iov(iter)->iov_base + (iter)->iov_offset)
static inline size_t iter_iov_len(const struct iov_iter *i)
{
if (i->iter_type == ITER_UBUF)
return i->count;
return iter_iov(i)->iov_len - i->iov_offset;
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/mm_types.h`, `linux/ucopysize.h`, `uapi/linux/uio.h`.
- Detected declarations: `struct page`, `struct folio_queue`, `struct kvec`, `struct iov_iter_state`, `struct iov_iter`, `struct uio_meta`, `struct sg_table`, `enum iter_type`, `function iter_iov_len`, `function iov_iter_type`.
- 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.