The seq_printf() will soon just return void, and seq_has_overflowed() should be used instead to see if the seq can no longer accept input. As the return value of debugfs_print_regs32() has no users and the seq_file descriptor should be checked with seq_has_overflowed() instead of return values of functions, it is better to just have debugfs_print_regs32() also return void. Link: http://lkml.kernel.org/p/2634b19eb1c04a9d31148c1fe6f1f3819be95349.1412031505.git.joe@perches.com Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joe Perches <joe@perches.com> [ original change only updated seq_printf() return, added return of void to debugfs_print_regs32() as well ] Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
		
			
				
	
	
		
			191 lines
		
	
	
	
		
			8.1 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			191 lines
		
	
	
	
		
			8.1 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
Copyright 2009 Jonathan Corbet <corbet@lwn.net>
 | 
						|
 | 
						|
Debugfs exists as a simple way for kernel developers to make information
 | 
						|
available to user space.  Unlike /proc, which is only meant for information
 | 
						|
about a process, or sysfs, which has strict one-value-per-file rules,
 | 
						|
debugfs has no rules at all.  Developers can put any information they want
 | 
						|
there.  The debugfs filesystem is also intended to not serve as a stable
 | 
						|
ABI to user space; in theory, there are no stability constraints placed on
 | 
						|
files exported there.  The real world is not always so simple, though [1];
 | 
						|
even debugfs interfaces are best designed with the idea that they will need
 | 
						|
to be maintained forever.
 | 
						|
 | 
						|
Debugfs is typically mounted with a command like:
 | 
						|
 | 
						|
    mount -t debugfs none /sys/kernel/debug
 | 
						|
 | 
						|
(Or an equivalent /etc/fstab line).
 | 
						|
The debugfs root directory is accessible only to the root user by
 | 
						|
default. To change access to the tree the "uid", "gid" and "mode" mount
 | 
						|
options can be used.
 | 
						|
 | 
						|
Note that the debugfs API is exported GPL-only to modules.
 | 
						|
 | 
						|
Code using debugfs should include <linux/debugfs.h>.  Then, the first order
 | 
						|
of business will be to create at least one directory to hold a set of
 | 
						|
debugfs files:
 | 
						|
 | 
						|
    struct dentry *debugfs_create_dir(const char *name, struct dentry *parent);
 | 
						|
 | 
						|
This call, if successful, will make a directory called name underneath the
 | 
						|
indicated parent directory.  If parent is NULL, the directory will be
 | 
						|
created in the debugfs root.  On success, the return value is a struct
 | 
						|
dentry pointer which can be used to create files in the directory (and to
 | 
						|
clean it up at the end).  A NULL return value indicates that something went
 | 
						|
wrong.  If ERR_PTR(-ENODEV) is returned, that is an indication that the
 | 
						|
kernel has been built without debugfs support and none of the functions
 | 
						|
described below will work.
 | 
						|
 | 
						|
The most general way to create a file within a debugfs directory is with:
 | 
						|
 | 
						|
    struct dentry *debugfs_create_file(const char *name, umode_t mode,
 | 
						|
				       struct dentry *parent, void *data,
 | 
						|
				       const struct file_operations *fops);
 | 
						|
 | 
						|
Here, name is the name of the file to create, mode describes the access
 | 
						|
permissions the file should have, parent indicates the directory which
 | 
						|
should hold the file, data will be stored in the i_private field of the
 | 
						|
resulting inode structure, and fops is a set of file operations which
 | 
						|
implement the file's behavior.  At a minimum, the read() and/or write()
 | 
						|
operations should be provided; others can be included as needed.  Again,
 | 
						|
the return value will be a dentry pointer to the created file, NULL for
 | 
						|
error, or ERR_PTR(-ENODEV) if debugfs support is missing.
 | 
						|
 | 
						|
In a number of cases, the creation of a set of file operations is not
 | 
						|
actually necessary; the debugfs code provides a number of helper functions
 | 
						|
for simple situations.  Files containing a single integer value can be
 | 
						|
created with any of:
 | 
						|
 | 
						|
    struct dentry *debugfs_create_u8(const char *name, umode_t mode,
 | 
						|
				     struct dentry *parent, u8 *value);
 | 
						|
    struct dentry *debugfs_create_u16(const char *name, umode_t mode,
 | 
						|
				      struct dentry *parent, u16 *value);
 | 
						|
    struct dentry *debugfs_create_u32(const char *name, umode_t mode,
 | 
						|
				      struct dentry *parent, u32 *value);
 | 
						|
    struct dentry *debugfs_create_u64(const char *name, umode_t mode,
 | 
						|
				      struct dentry *parent, u64 *value);
 | 
						|
 | 
						|
These files support both reading and writing the given value; if a specific
 | 
						|
file should not be written to, simply set the mode bits accordingly.  The
 | 
						|
values in these files are in decimal; if hexadecimal is more appropriate,
 | 
						|
the following functions can be used instead:
 | 
						|
 | 
						|
    struct dentry *debugfs_create_x8(const char *name, umode_t mode,
 | 
						|
				     struct dentry *parent, u8 *value);
 | 
						|
    struct dentry *debugfs_create_x16(const char *name, umode_t mode,
 | 
						|
				      struct dentry *parent, u16 *value);
 | 
						|
    struct dentry *debugfs_create_x32(const char *name, umode_t mode,
 | 
						|
				      struct dentry *parent, u32 *value);
 | 
						|
    struct dentry *debugfs_create_x64(const char *name, umode_t mode,
 | 
						|
				      struct dentry *parent, u64 *value);
 | 
						|
 | 
						|
These functions are useful as long as the developer knows the size of the
 | 
						|
value to be exported.  Some types can have different widths on different
 | 
						|
architectures, though, complicating the situation somewhat.  There is a
 | 
						|
function meant to help out in one special case:
 | 
						|
 | 
						|
    struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
 | 
						|
				         struct dentry *parent, 
 | 
						|
					 size_t *value);
 | 
						|
 | 
						|
As might be expected, this function will create a debugfs file to represent
 | 
						|
a variable of type size_t.
 | 
						|
 | 
						|
Boolean values can be placed in debugfs with:
 | 
						|
 | 
						|
    struct dentry *debugfs_create_bool(const char *name, umode_t mode,
 | 
						|
				       struct dentry *parent, u32 *value);
 | 
						|
 | 
						|
A read on the resulting file will yield either Y (for non-zero values) or
 | 
						|
N, followed by a newline.  If written to, it will accept either upper- or
 | 
						|
lower-case values, or 1 or 0.  Any other input will be silently ignored.
 | 
						|
 | 
						|
Another option is exporting a block of arbitrary binary data, with
 | 
						|
this structure and function:
 | 
						|
 | 
						|
    struct debugfs_blob_wrapper {
 | 
						|
	void *data;
 | 
						|
	unsigned long size;
 | 
						|
    };
 | 
						|
 | 
						|
    struct dentry *debugfs_create_blob(const char *name, umode_t mode,
 | 
						|
				       struct dentry *parent,
 | 
						|
				       struct debugfs_blob_wrapper *blob);
 | 
						|
 | 
						|
A read of this file will return the data pointed to by the
 | 
						|
debugfs_blob_wrapper structure.  Some drivers use "blobs" as a simple way
 | 
						|
to return several lines of (static) formatted text output.  This function
 | 
						|
can be used to export binary information, but there does not appear to be
 | 
						|
any code which does so in the mainline.  Note that all files created with
 | 
						|
debugfs_create_blob() are read-only.
 | 
						|
 | 
						|
If you want to dump a block of registers (something that happens quite
 | 
						|
often during development, even if little such code reaches mainline.
 | 
						|
Debugfs offers two functions: one to make a registers-only file, and
 | 
						|
another to insert a register block in the middle of another sequential
 | 
						|
file.
 | 
						|
 | 
						|
    struct debugfs_reg32 {
 | 
						|
	char *name;
 | 
						|
	unsigned long offset;
 | 
						|
    };
 | 
						|
 | 
						|
    struct debugfs_regset32 {
 | 
						|
	struct debugfs_reg32 *regs;
 | 
						|
	int nregs;
 | 
						|
	void __iomem *base;
 | 
						|
    };
 | 
						|
 | 
						|
    struct dentry *debugfs_create_regset32(const char *name, umode_t mode,
 | 
						|
				     struct dentry *parent,
 | 
						|
				     struct debugfs_regset32 *regset);
 | 
						|
 | 
						|
    void debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,
 | 
						|
			 int nregs, void __iomem *base, char *prefix);
 | 
						|
 | 
						|
The "base" argument may be 0, but you may want to build the reg32 array
 | 
						|
using __stringify, and a number of register names (macros) are actually
 | 
						|
byte offsets over a base for the register block.
 | 
						|
 | 
						|
 | 
						|
There are a couple of other directory-oriented helper functions:
 | 
						|
 | 
						|
    struct dentry *debugfs_rename(struct dentry *old_dir, 
 | 
						|
    				  struct dentry *old_dentry,
 | 
						|
		                  struct dentry *new_dir, 
 | 
						|
				  const char *new_name);
 | 
						|
 | 
						|
    struct dentry *debugfs_create_symlink(const char *name, 
 | 
						|
                                          struct dentry *parent,
 | 
						|
				      	  const char *target);
 | 
						|
 | 
						|
A call to debugfs_rename() will give a new name to an existing debugfs
 | 
						|
file, possibly in a different directory.  The new_name must not exist prior
 | 
						|
to the call; the return value is old_dentry with updated information.
 | 
						|
Symbolic links can be created with debugfs_create_symlink().
 | 
						|
 | 
						|
There is one important thing that all debugfs users must take into account:
 | 
						|
there is no automatic cleanup of any directories created in debugfs.  If a
 | 
						|
module is unloaded without explicitly removing debugfs entries, the result
 | 
						|
will be a lot of stale pointers and no end of highly antisocial behavior.
 | 
						|
So all debugfs users - at least those which can be built as modules - must
 | 
						|
be prepared to remove all files and directories they create there.  A file
 | 
						|
can be removed with:
 | 
						|
 | 
						|
    void debugfs_remove(struct dentry *dentry);
 | 
						|
 | 
						|
The dentry value can be NULL, in which case nothing will be removed.
 | 
						|
 | 
						|
Once upon a time, debugfs users were required to remember the dentry
 | 
						|
pointer for every debugfs file they created so that all files could be
 | 
						|
cleaned up.  We live in more civilized times now, though, and debugfs users
 | 
						|
can call:
 | 
						|
 | 
						|
    void debugfs_remove_recursive(struct dentry *dentry);
 | 
						|
 | 
						|
If this function is passed a pointer for the dentry corresponding to the
 | 
						|
top-level directory, the entire hierarchy below that directory will be
 | 
						|
removed.
 | 
						|
 | 
						|
Notes:
 | 
						|
	[1] http://lwn.net/Articles/309298/
 |