Documentation/filesystems/seq_file.rst
Source file repositories/reference/linux-study-clean/Documentation/filesystems/seq_file.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/filesystems/seq_file.rst- Extension
.rst- Size
- 16363 bytes
- Lines
- 397
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: operation-table or driver-model contract
- Status
- pattern implementation candidate
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- 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
- No C-style include directives detected by the generator.
Detected Declarations
function startfunction startfunction ct_seq_showfunction ct_openfunction seq_openfunction ct_openfunction seq_release_privatemodule init ct_init
Annotated Snippet
static const struct file_operations ct_file_ops = {
.owner = THIS_MODULE,
.open = ct_open,
.read = seq_read,
.llseek = seq_lseek,
.release = seq_release
};
There is also a seq_release_private() which passes the contents of the
seq_file private field to kfree() before releasing the structure.
The final step is the creation of the /proc file itself. In the example
code, that is done in the initialization code in the usual way::
static int ct_init(void)
{
struct proc_dir_entry *entry;
proc_create("sequence", 0, NULL, &ct_file_ops);
return 0;
}
module_init(ct_init);
And that is pretty much it.
seq_list
========
If your file will be iterating through a linked list, you may find these
routines useful::
struct list_head *seq_list_start(struct list_head *head,
loff_t pos);
struct list_head *seq_list_start_head(struct list_head *head,
loff_t pos);
struct list_head *seq_list_next(void *v, struct list_head *head,
loff_t *ppos);
These helpers will interpret pos as a position within the list and iterate
accordingly. Your start() and next() functions need only invoke the
``seq_list_*`` helpers with a pointer to the appropriate list_head structure.
The extra-simple version
========================
For extremely simple virtual files, there is an even easier interface. A
module can define only the show() function, which should create all the
output that the virtual file will contain. The file's open() method then
calls::
int single_open(struct file *file,
int (*show)(struct seq_file *m, void *p),
void *data);
When output time comes, the show() function will be called once. The data
value given to single_open() can be found in the private field of the
seq_file structure. When using single_open(), the programmer should use
single_release() instead of seq_release() in the file_operations structure
to avoid a memory leak.
Annotation
- Detected declarations: `function start`, `function start`, `function ct_seq_show`, `function ct_open`, `function seq_open`, `function ct_open`, `function seq_release_private`, `module init ct_init`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: pattern 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.