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.
~65 more replies (not shown)
kinda becoming more sympathetic to the idea that you need to read documentation to use kernel stuff correctly. usually you can't expect documentation to be good
nice i'm gonna use these functions for this module for sure
There are also a pair of functions for printing filenames::
int seq_path(struct seq_file *m, const struct path *path,
const char *esc);
int seq_path_root(struct seq_file *m, const struct path *path,
const struct path *root, const char *esc)
A true return from seq_has_overflowed means that the seq_file buffer will
be discarded and the seq_show function will attempt to allocate a larger
buffer and retry printing.
oh love this so much too Documentation/filesystems/api-summary.rst specifically links to source code as well as other documentation elevating source code as a form of documentation
like usually when people tell you shit like "my code is self-documenting" they don't specifically point to which code is the documentation you should be looking at bc it's obviously a dodge this instead takes ownership of that
kind of interesting that procfs seems to be entirely about producing text output for humans to consider as opposed to binary communication formats. i suppose if you wanted to do binary communication with the kernel you would use a syscall for that
love this shit
* %__GFP_RETRY_MAYFAIL
* Try really hard to succeed the allocation but fail
* eventually.
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled