just found Documentation/filesystems/seq_file.rst in the kernel and this seems to do everything i want. was having difficulty finding info about how to do a virtual proc file but it's probably because everything is just using seq_file
Discussion
Loading...
i had actually seen it before because it was also the one place which mentioned the deprecated API create_proc_entry() but i didn't realize i was looking at the procfile documentation in general lol
this is just useful to know about how the fs layer works in general
A seq_file implementation that is formatting firewall rules from a
table, for example, could provide a simple iterator that interprets
position N as the Nth rule in the chain. A seq_file implementation
that presents the content of a, potentially volatile, linked list
might record a pointer into that list, providing that can be done
without risk of the current location being removed.Positioning can thus be done in whatever way makes the most sense for
the generator of the data, which need not be aware of how a position
translates to an offset in the virtual file. The one obvious exception
is that a position of zero should indicate the beginning of the file.
i know that directory streams do not use an integer offset but more like an opaque "cookie" referencing a hash table entry these days
there's so much cool stuff in /proc/self/ lol
this documentation is so good lol. being honest about historical issues is so refreshing
The next() function should set
*posto a value that start() can use
to find the new location in the sequence. When the iterator is being
stored in the private data area, rather than being reinitialized on each
start(), it might seem sufficient to simply set*posto any non-zero
value (zero always tells start() to restart the sequence). This is not
sufficient due to historical problems.Historically, many next() functions have not updated
*posat
end-of-file. If the value is then used by start() to initialise the
iterator, this can result in corner cases where the last entry in the
sequence is reported twice in the file. In order to discourage this bug
from being resurrected, the core seq_file code now produces a warning if
a next() function does not change the value of*pos. Consequently a
next() function must change the value of*pos, and of course must
set it to a non-zero value.
literally it's good
It's worth noting that the iterator value returned by start() and
manipulated by the other functions is considered to be completely opaque by
the seq_file code. It can thus be anything that is useful in stepping
through the data to be output. Counters can be useful, but it could also be
a direct pointer into an array or linked list. Anything goes, as long as
the programmer is aware that things can happen between calls to the
iterator function. However, the seq_file code (by design) will not sleep
between the calls to start() and stop(), so holding a lock during that time
is a reasonable thing to do. The seq_file code will also avoid taking any
other locks while the iterator is active.
1+ more replies (not shown)
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled