1.. SPDX-License-Identifier: GPL-2.0
   4The seq_file Interface
   7        Copyright 2003 Jonathan Corbet <>
   9        This file is originally from the Driver Porting series at
  13There are numerous ways for a device driver (or other kernel component) to
  14provide information to the user or system administrator.  One useful
  15technique is the creation of virtual files, in debugfs, /proc or elsewhere.
  16Virtual files can provide human-readable output that is easy to get at
  17without any special utility programs; they can also make life easier for
  18script writers. It is not surprising that the use of virtual files has
  19grown over the years.
  21Creating those files correctly has always been a bit of a challenge,
  22however. It is not that hard to make a virtual file which returns a
  23string. But life gets trickier if the output is long - anything greater
  24than an application is likely to read in a single operation.  Handling
  25multiple reads (and seeks) requires careful attention to the reader's
  26position within the virtual file - that position is, likely as not, in the
  27middle of a line of output. The kernel has traditionally had a number of
  28implementations that got this wrong.
  30The 2.6 kernel contains a set of functions (implemented by Alexander Viro)
  31which are designed to make it easy for virtual file creators to get it
  34The seq_file interface is available via <linux/seq_file.h>. There are
  35three aspects to seq_file:
  37     * An iterator interface which lets a virtual file implementation
  38       step through the objects it is presenting.
  40     * Some utility functions for formatting objects for output without
  41       needing to worry about things like output buffers.
  43     * A set of canned file_operations which implement most operations on
  44       the virtual file.
  46We'll look at the seq_file interface via an extremely simple example: a
  47loadable module which creates a file called /proc/sequence. The file, when
  48read, simply produces a set of increasing integer values, one per line. The
  49sequence will continue until the user loses patience and finds something
  50better to do. The file is seekable, in that one can do something like the
  53    dd if=/proc/sequence of=out1 count=1
  54    dd if=/proc/sequence skip=1 of=out2 count=1
  56Then concatenate the output files out1 and out2 and get the right
  57result. Yes, it is a thoroughly useless module, but the point is to show
  58how the mechanism works without getting lost in other details.  (Those
  59wanting to see the full source for this module can find it at
  62Deprecated create_proc_entry
  65Note that the above article uses create_proc_entry which was removed in
  66kernel 3.10. Current versions require the following update::
  68    -   entry = create_proc_entry("sequence", 0, NULL);
  69    -   if (entry)
  70    -           entry->proc_fops = &ct_file_ops;
  71    +   entry = proc_create("sequence", 0, NULL, &ct_file_ops);
  73The iterator interface
  76Modules implementing a virtual file with seq_file must implement an
  77iterator object that allows stepping through the data of interest
  78during a "session" (roughly one read() system call).  If the iterator
  79is able to move to a specific position - like the file they implement,
  80though with freedom to map the position number to a sequence location
  81in whatever way is convenient - the iterator need only exist
  82transiently during a session.  If the iterator cannot easily find a
  83numerical position but works well with a first/next interface, the
  84iterator can be stored in the private data area and continue from one
  85session to the next.
  87A seq_file implementation that is formatting firewall rules from a
  88table, for example, could provide a simple iterator that interprets
  89position N as the Nth rule in the chain.  A seq_file implementation
  90that presents the content of a, potentially volatile, linked list
  91might record a pointer into that list, providing that can be done
  92without risk of the current location being removed.
  94Positioning can thus be done in whatever way makes the most sense for
  95the generator of the data, which need not be aware of how a position
  96translates to an offset in the virtual file. The one obvious exception
  97is that a position of zero should indicate the beginning of the file.
  99The /proc/sequence iterator just uses the count of the next number it
 100will output as its position.
 102Four functions must be implemented to make the iterator work. The
 103first, called start(), starts a session and takes a position as an
 104argument, returning an iterator which will start reading at that
 105position.  The pos passed to start() will always be either zero, or
 106the most recent pos used in the previous session.
 108For our simple sequence example,
 109the start() function looks like::
 111        static void *ct_seq_start(struct seq_file *s, loff_t *pos)
 112        {
 113                loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);
 114                if (! spos)
 115                        return NULL;
 116                *spos = *pos;
 117                return spos;
 118        }
 120The entire data structure for this iterator is a single loff_t value
 121holding the current position. There is no upper bound for the sequence
 122iterator, but that will not be the case for most other seq_file
 123implementations; in most cases the start() function should check for a
 124"past end of file" condition and return NULL if need be.
 126For more complicated applications, the private field of the seq_file
 127structure can be used to hold state from session to session.  There is
 128also a special value which can be returned by the start() function
 129called SEQ_START_TOKEN; it can be used if you wish to instruct your
 130show() function (described below) to print a header at the top of the
 131output. SEQ_START_TOKEN should only be used if the offset is zero,
 132however.  SEQ_START_TOKEN has no special meaning to the core seq_file
 133code.  It is provided as a convenience for a start() funciton to
 134communicate with the next() and show() functions.
 136The next function to implement is called, amazingly, next(); its job is to
 137move the iterator forward to the next position in the sequence.  The
 138example module can simply increment the position by one; more useful
 139modules will do what is needed to step through some data structure. The
 140next() function returns a new iterator, or NULL if the sequence is
 141complete. Here's the example version::
 143        static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
 144        {
 145                loff_t *spos = v;
 146                *pos = ++*spos;
 147                return spos;
 148        }
 150The next() function should set ``*pos`` to a value that start() can use
 151to find the new location in the sequence.  When the iterator is being
 152stored in the private data area, rather than being reinitialized on each
 153start(), it might seem sufficient to simply set ``*pos`` to any non-zero
 154value (zero always tells start() to restart the sequence).  This is not
 155sufficient due to historical problems.
 157Historically, many next() functions have *not* updated ``*pos`` at
 158end-of-file.  If the value is then used by start() to initialise the
 159iterator, this can result in corner cases where the last entry in the
 160sequence is reported twice in the file.  In order to discourage this bug
 161from being resurrected, the core seq_file code now produces a warning if
 162a next() function does not change the value of ``*pos``.  Consequently a
 163next() function *must* change the value of ``*pos``, and of course must
 164set it to a non-zero value.
 166The stop() function closes a session; its job, of course, is to clean
 167up. If dynamic memory is allocated for the iterator, stop() is the
 168place to free it; if a lock was taken by start(), stop() must release
 169that lock.  The value that ``*pos`` was set to by the last next() call
 170before stop() is remembered, and used for the first start() call of
 171the next session unless lseek() has been called on the file; in that
 172case next start() will be asked to start at position zero::
 174        static void ct_seq_stop(struct seq_file *s, void *v)
 175        {
 176                kfree(v);
 177        }
 179Finally, the show() function should format the object currently pointed to
 180by the iterator for output.  The example module's show() function is::
 182        static int ct_seq_show(struct seq_file *s, void *v)
 183        {
 184                loff_t *spos = v;
 185                seq_printf(s, "%lld\n", (long long)*spos);
 186                return 0;
 187        }
 189If all is well, the show() function should return zero.  A negative error
 190code in the usual manner indicates that something went wrong; it will be
 191passed back to user space.  This function can also return SEQ_SKIP, which
 192causes the current item to be skipped; if the show() function has already
 193generated output before returning SEQ_SKIP, that output will be dropped.
 195We will look at seq_printf() in a moment. But first, the definition of the
 196seq_file iterator is finished by creating a seq_operations structure with
 197the four functions we have just defined::
 199        static const struct seq_operations ct_seq_ops = {
 200                .start = ct_seq_start,
 201                .next  = ct_seq_next,
 202                .stop  = ct_seq_stop,
 203                .show  = ct_seq_show
 204        };
 206This structure will be needed to tie our iterator to the /proc file in
 207a little bit.
 209It's worth noting that the iterator value returned by start() and
 210manipulated by the other functions is considered to be completely opaque by
 211the seq_file code. It can thus be anything that is useful in stepping
 212through the data to be output. Counters can be useful, but it could also be
 213a direct pointer into an array or linked list. Anything goes, as long as
 214the programmer is aware that things can happen between calls to the
 215iterator function. However, the seq_file code (by design) will not sleep
 216between the calls to start() and stop(), so holding a lock during that time
 217is a reasonable thing to do. The seq_file code will also avoid taking any
 218other locks while the iterator is active.
 220The iterater value returned by start() or next() is guaranteed to be
 221passed to a subsequent next() or stop() call.  This allows resources
 222such as locks that were taken to be reliably released.  There is *no*
 223guarantee that the iterator will be passed to show(), though in practice
 224it often will be.
 227Formatted output
 230The seq_file code manages positioning within the output created by the
 231iterator and getting it into the user's buffer. But, for that to work, that
 232output must be passed to the seq_file code. Some utility functions have
 233been defined which make this task easy.
 235Most code will simply use seq_printf(), which works pretty much like
 236printk(), but which requires the seq_file pointer as an argument.
 238For straight character output, the following functions may be used::
 240        seq_putc(struct seq_file *m, char c);
 241        seq_puts(struct seq_file *m, const char *s);
 242        seq_escape(struct seq_file *m, const char *s, const char *esc);
 244The first two output a single character and a string, just like one would
 245expect. seq_escape() is like seq_puts(), except that any character in s
 246which is in the string esc will be represented in octal form in the output.
 248There are also a pair of functions for printing filenames::
 250        int seq_path(struct seq_file *m, const struct path *path,
 251                     const char *esc);
 252        int seq_path_root(struct seq_file *m, const struct path *path,
 253                          const struct path *root, const char *esc)
 255Here, path indicates the file of interest, and esc is a set of characters
 256which should be escaped in the output.  A call to seq_path() will output
 257the path relative to the current process's filesystem root.  If a different
 258root is desired, it can be used with seq_path_root().  If it turns out that
 259path cannot be reached from root, seq_path_root() returns SEQ_SKIP.
 261A function producing complicated output may want to check::
 263        bool seq_has_overflowed(struct seq_file *m);
 265and avoid further seq_<output> calls if true is returned.
 267A true return from seq_has_overflowed means that the seq_file buffer will
 268be discarded and the seq_show function will attempt to allocate a larger
 269buffer and retry printing.
 272Making it all work
 275So far, we have a nice set of functions which can produce output within the
 276seq_file system, but we have not yet turned them into a file that a user
 277can see. Creating a file within the kernel requires, of course, the
 278creation of a set of file_operations which implement the operations on that
 279file. The seq_file interface provides a set of canned operations which do
 280most of the work. The virtual file author still must implement the open()
 281method, however, to hook everything up. The open function is often a single
 282line, as in the example module::
 284        static int ct_open(struct inode *inode, struct file *file)
 285        {
 286                return seq_open(file, &ct_seq_ops);
 287        }
 289Here, the call to seq_open() takes the seq_operations structure we created
 290before, and gets set up to iterate through the virtual file.
 292On a successful open, seq_open() stores the struct seq_file pointer in
 293file->private_data. If you have an application where the same iterator can
 294be used for more than one file, you can store an arbitrary pointer in the
 295private field of the seq_file structure; that value can then be retrieved
 296by the iterator functions.
 298There is also a wrapper function to seq_open() called seq_open_private(). It
 299kmallocs a zero filled block of memory and stores a pointer to it in the
 300private field of the seq_file structure, returning 0 on success. The
 301block size is specified in a third parameter to the function, e.g.::
 303        static int ct_open(struct inode *inode, struct file *file)
 304        {
 305                return seq_open_private(file, &ct_seq_ops,
 306                                        sizeof(struct mystruct));
 307        }
 309There is also a variant function, __seq_open_private(), which is functionally
 310identical except that, if successful, it returns the pointer to the allocated
 311memory block, allowing further initialisation e.g.::
 313        static int ct_open(struct inode *inode, struct file *file)
 314        {
 315                struct mystruct *p =
 316                        __seq_open_private(file, &ct_seq_ops, sizeof(*p));
 318                if (!p)
 319                        return -ENOMEM;
 321                p->foo = bar; /* initialize my stuff */
 322                        ...
 323                p->baz = true;
 325                return 0;
 326        }
 328A corresponding close function, seq_release_private() is available which
 329frees the memory allocated in the corresponding open.
 331The other operations of interest - read(), llseek(), and release() - are
 332all implemented by the seq_file code itself. So a virtual file's
 333file_operations structure will look like::
 335        static const struct file_operations ct_file_ops = {
 336                .owner   = THIS_MODULE,
 337                .open    = ct_open,
 338                .read    = seq_read,
 339                .llseek  = seq_lseek,
 340                .release = seq_release
 341        };
 343There is also a seq_release_private() which passes the contents of the
 344seq_file private field to kfree() before releasing the structure.
 346The final step is the creation of the /proc file itself. In the example
 347code, that is done in the initialization code in the usual way::
 349        static int ct_init(void)
 350        {
 351                struct proc_dir_entry *entry;
 353                proc_create("sequence", 0, NULL, &ct_file_ops);
 354                return 0;
 355        }
 357        module_init(ct_init);
 359And that is pretty much it.
 365If your file will be iterating through a linked list, you may find these
 366routines useful::
 368        struct list_head *seq_list_start(struct list_head *head,
 369                                         loff_t pos);
 370        struct list_head *seq_list_start_head(struct list_head *head,
 371                                              loff_t pos);
 372        struct list_head *seq_list_next(void *v, struct list_head *head,
 373                                        loff_t *ppos);
 375These helpers will interpret pos as a position within the list and iterate
 376accordingly.  Your start() and next() functions need only invoke the
 377``seq_list_*`` helpers with a pointer to the appropriate list_head structure.
 380The extra-simple version
 383For extremely simple virtual files, there is an even easier interface.  A
 384module can define only the show() function, which should create all the
 385output that the virtual file will contain. The file's open() method then
 388        int single_open(struct file *file,
 389                        int (*show)(struct seq_file *m, void *p),
 390                        void *data);
 392When output time comes, the show() function will be called once. The data
 393value given to single_open() can be found in the private field of the
 394seq_file structure. When using single_open(), the programmer should use
 395single_release() instead of seq_release() in the file_operations structure
 396to avoid a memory leak.