in a future newbie column, i plan on covering the creation and usage of /proc files, if only to the extent of creating them just for the purpose of reading them to aid in kernel debugging. if you read the presentation of proc files in LDD3, ch 4, here: http://lwn.net/Kernel/LDD3/ what is presented first is the old (deprecated) way of defining a proc file, then the current way, followed by the even newer "seq" files. it seems, upon examination, that seq files is the way to go these days (even for short files), based on what i see in the kernel source directory fs/proc. for instance, here's the implementation of /proc/version (from fs/proc/version.c): ===== #include <linux/fs.h> #include <linux/init.h> #include <linux/kernel.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> #include <linux/utsname.h> static int version_proc_show(struct seq_file *m, void *v) { seq_printf(m, linux_proc_banner, utsname()->sysname, utsname()->release, utsname()->version); return 0; } static int version_proc_open(struct inode *inode, struct file *file) { return single_open(file, version_proc_show, NULL); } static const struct file_operations version_proc_fops = { .open = version_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static int __init proc_version_init(void) { proc_create("version", 0, NULL, &version_proc_fops); return 0; } module_init(proc_version_init); ===== that is an implementation of an entirely self-contained, readable proc file (/proc/version), which generates its output in a single operation since it's based on a couple functions i'd actually never noticed before -- single_open() and single_release(). i can only assume that those routines are special cases meant to represent that reading this proc file is done all at once, and doesn't involve any iteration, and that the above is a perfectly reasonable and canonical model for *all* /proc files whose purpose is to provide a small amount of read-only info, is that correct? the same could be said for fs/proc/meminfo.c -- that again uses the special cases of single_open() and single_release() -- even though that example dumps out a *considerable* amount of output, it's still a one-shot deal. the other variation is when an iterator *is* used, as in, say, /proc/devices (fs/proc/devices.c), at which point the seq file reverts back to the use of the regular seq_open() and seq_release(). does all that make sense? so, in summary, it looks like, for (read-only) debugging-oriented /proc files, you might as well just use seq files and there are two possibilities: 1) little output? use /proc/version as a model 2) lots of iterative-flavoured output? use /proc/devices as a model if i want to keep things simple, i see little reason to go beyond those two examples, since they're perfect examples of using proc files for debugging. thoughts? rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday "Kernel Newbie Corner" column @ linux.com: http://cli.gs/WG6WYX ======================================================================== -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
