blob: 7e81e37c0b1ec0ccbea30a92ffbf70f495ffdbd0 [file] [log] [blame]
Linus Torvalds1da177e2005-04-16 15:20:36 -07001
2sysfs - _The_ filesystem for exporting kernel objects.
3
4Patrick Mochel <mochel@osdl.org>
Mike Murphyf8a1af62009-02-22 01:19:23 -05005Mike Murphy <mamurph@cs.clemson.edu>
Linus Torvalds1da177e2005-04-16 15:20:36 -07006
Mike Murphyf8a1af62009-02-22 01:19:23 -05007Revised: 22 February 2009
8Original: 10 January 2003
Linus Torvalds1da177e2005-04-16 15:20:36 -07009
10
11What it is:
12~~~~~~~~~~~
13
14sysfs is a ram-based filesystem initially based on ramfs. It provides
15a means to export kernel data structures, their attributes, and the
16linkages between them to userspace.
17
18sysfs is tied inherently to the kobject infrastructure. Please read
19Documentation/kobject.txt for more information concerning the kobject
20interface.
21
22
23Using sysfs
24~~~~~~~~~~~
25
26sysfs is always compiled in. You can access it by doing:
27
28 mount -t sysfs sysfs /sys
29
30
31Directory Creation
32~~~~~~~~~~~~~~~~~~
33
34For every kobject that is registered with the system, a directory is
35created for it in sysfs. That directory is created as a subdirectory
36of the kobject's parent, expressing internal object hierarchies to
37userspace. Top-level directories in sysfs represent the common
38ancestors of object hierarchies; i.e. the subsystems the objects
39belong to.
40
41Sysfs internally stores the kobject that owns the directory in the
42->d_fsdata pointer of the directory's dentry. This allows sysfs to do
43reference counting directly on the kobject when the file is opened and
44closed.
45
46
47Attributes
48~~~~~~~~~~
49
50Attributes can be exported for kobjects in the form of regular files in
51the filesystem. Sysfs forwards file I/O operations to methods defined
52for the attributes, providing a means to read and write kernel
53attributes.
54
55Attributes should be ASCII text files, preferably with only one value
Shaun Zinckf8c34f92007-10-20 02:39:43 +020056per file. It is noted that it may not be efficient to contain only one
Linus Torvalds1da177e2005-04-16 15:20:36 -070057value per file, so it is socially acceptable to express an array of
58values of the same type.
59
60Mixing types, expressing multiple lines of data, and doing fancy
61formatting of data is heavily frowned upon. Doing these things may get
62you publically humiliated and your code rewritten without notice.
63
64
65An attribute definition is simply:
66
67struct attribute {
68 char * name;
Mike Murphyf8a1af62009-02-22 01:19:23 -050069 struct module *owner;
Linus Torvalds1da177e2005-04-16 15:20:36 -070070 mode_t mode;
71};
72
73
Mike Murphyf8a1af62009-02-22 01:19:23 -050074int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
75void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
Linus Torvalds1da177e2005-04-16 15:20:36 -070076
77
78A bare attribute contains no means to read or write the value of the
79attribute. Subsystems are encouraged to define their own attribute
80structure and wrapper functions for adding and removing attributes for
81a specific object type.
82
83For example, the driver model defines struct device_attribute like:
84
85struct device_attribute {
Mike Murphyf8a1af62009-02-22 01:19:23 -050086 struct attribute attr;
87 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
88 char *buf);
89 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
90 const char *buf, size_t count);
Linus Torvalds1da177e2005-04-16 15:20:36 -070091};
92
93int device_create_file(struct device *, struct device_attribute *);
94void device_remove_file(struct device *, struct device_attribute *);
95
96It also defines this helper for defining device attributes:
97
Mike Murphyf8a1af62009-02-22 01:19:23 -050098#define DEVICE_ATTR(_name, _mode, _show, _store) \
99struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
Linus Torvalds1da177e2005-04-16 15:20:36 -0700100
101For example, declaring
102
Jan Veldeman91e49002005-07-31 13:12:10 +0200103static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700104
105is equivalent to doing:
106
107static struct device_attribute dev_attr_foo = {
108 .attr = {
109 .name = "foo",
Jan Veldeman91e49002005-07-31 13:12:10 +0200110 .mode = S_IWUSR | S_IRUGO,
Mike Murphyf8a1af62009-02-22 01:19:23 -0500111 .show = show_foo,
112 .store = store_foo,
Linus Torvalds1da177e2005-04-16 15:20:36 -0700113 },
Linus Torvalds1da177e2005-04-16 15:20:36 -0700114};
115
116
117Subsystem-Specific Callbacks
118~~~~~~~~~~~~~~~~~~~~~~~~~~~~
119
120When a subsystem defines a new attribute type, it must implement a
121set of sysfs operations for forwarding read and write calls to the
122show and store methods of the attribute owners.
123
124struct sysfs_ops {
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200125 ssize_t (*show)(struct kobject *, struct attribute *, char *);
126 ssize_t (*store)(struct kobject *, struct attribute *, const char *);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700127};
128
129[ Subsystems should have already defined a struct kobj_type as a
130descriptor for this type, which is where the sysfs_ops pointer is
131stored. See the kobject documentation for more information. ]
132
133When a file is read or written, sysfs calls the appropriate method
134for the type. The method then translates the generic struct kobject
135and struct attribute pointers to the appropriate pointer types, and
136calls the associated methods.
137
138
139To illustrate:
140
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200141#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
Linus Torvalds1da177e2005-04-16 15:20:36 -0700142#define to_dev(d) container_of(d, struct device, kobj)
143
144static ssize_t
145dev_attr_show(struct kobject * kobj, struct attribute * attr, char * buf)
146{
147 struct device_attribute * dev_attr = to_dev_attr(attr);
148 struct device * dev = to_dev(kobj);
149 ssize_t ret = 0;
150
151 if (dev_attr->show)
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200152 ret = dev_attr->show(dev, buf);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700153 return ret;
154}
155
156
157
158Reading/Writing Attribute Data
159~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
160
161To read or write attributes, show() or store() methods must be
162specified when declaring the attribute. The method types should be as
163simple as those defined for device attributes:
164
Mike Murphyf8a1af62009-02-22 01:19:23 -0500165ssize_t (*show)(struct device * dev, struct device_attribute * attr,
166 char * buf);
167ssize_t (*store)(struct device * dev, struct device_attribute * attr,
168 const char * buf);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700169
Mike Murphyf8a1af62009-02-22 01:19:23 -0500170IOW, they should take only an object, an attribute, and a buffer as parameters.
Linus Torvalds1da177e2005-04-16 15:20:36 -0700171
172
173sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the
174method. Sysfs will call the method exactly once for each read or
175write. This forces the following behavior on the method
176implementations:
177
178- On read(2), the show() method should fill the entire buffer.
179 Recall that an attribute should only be exporting one value, or an
180 array of similar values, so this shouldn't be that expensive.
181
Dan Williams2424b5d2008-04-07 15:35:01 -0700182 This allows userspace to do partial reads and forward seeks
183 arbitrarily over the entire file at will. If userspace seeks back to
184 zero or does a pread(2) with an offset of '0' the show() method will
185 be called again, rearmed, to fill the buffer.
Linus Torvalds1da177e2005-04-16 15:20:36 -0700186
187- On write(2), sysfs expects the entire buffer to be passed during the
188 first write. Sysfs then passes the entire buffer to the store()
189 method.
190
191 When writing sysfs files, userspace processes should first read the
192 entire file, modify the values it wishes to change, then write the
193 entire buffer back.
194
195 Attribute method implementations should operate on an identical
196 buffer when reading and writing values.
197
198Other notes:
199
Dan Williams2424b5d2008-04-07 15:35:01 -0700200- Writing causes the show() method to be rearmed regardless of current
201 file position.
202
Linus Torvalds1da177e2005-04-16 15:20:36 -0700203- The buffer will always be PAGE_SIZE bytes in length. On i386, this
204 is 4096.
205
206- show() methods should return the number of bytes printed into the
207 buffer. This is the return value of snprintf().
208
209- show() should always use snprintf().
210
211- store() should return the number of bytes used from the buffer. This
212 can be done using strlen().
213
214- show() or store() can always return errors. If a bad value comes
215 through, be sure to return an error.
216
217- The object passed to the methods will be pinned in memory via sysfs
218 referencing counting its embedded object. However, the physical
219 entity (e.g. device) the object represents may not be present. Be
220 sure to have a way to check this, if necessary.
221
222
223A very simple (and naive) implementation of a device attribute is:
224
Yani Ioannou3eb8c782005-05-17 06:40:28 -0400225static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)
Linus Torvalds1da177e2005-04-16 15:20:36 -0700226{
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200227 return snprintf(buf, PAGE_SIZE, "%s\n", dev->name);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700228}
229
230static ssize_t store_name(struct device * dev, const char * buf)
231{
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200232 sscanf(buf, "%20s", dev->name);
233 return strnlen(buf, PAGE_SIZE);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700234}
235
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200236static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700237
238
239(Note that the real implementation doesn't allow userspace to set the
240name for a device.)
241
242
243Top Level Directory Layout
244~~~~~~~~~~~~~~~~~~~~~~~~~~
245
246The sysfs directory arrangement exposes the relationship of kernel
247data structures.
248
Matt LaPlantefff92892006-10-03 22:47:42 +0200249The top level sysfs directory looks like:
Linus Torvalds1da177e2005-04-16 15:20:36 -0700250
251block/
252bus/
253class/
Dan Williamse105b8b2008-04-21 10:51:07 -0700254dev/
Linus Torvalds1da177e2005-04-16 15:20:36 -0700255devices/
256firmware/
257net/
Miklos Szeredic86d90d2006-04-26 10:49:26 +0200258fs/
Linus Torvalds1da177e2005-04-16 15:20:36 -0700259
260devices/ contains a filesystem representation of the device tree. It maps
261directly to the internal kernel device tree, which is a hierarchy of
262struct device.
263
264bus/ contains flat directory layout of the various bus types in the
265kernel. Each bus's directory contains two subdirectories:
266
267 devices/
268 drivers/
269
270devices/ contains symlinks for each device discovered in the system
271that point to the device's directory under root/.
272
273drivers/ contains a directory for each device driver that is loaded
274for devices on that particular bus (this assumes that drivers do not
275span multiple bus types).
276
Miklos Szeredic86d90d2006-04-26 10:49:26 +0200277fs/ contains a directory for some filesystems. Currently each
278filesystem wanting to export attributes must create its own hierarchy
279below fs/ (see ./fuse.txt for an example).
280
Dan Williamse105b8b2008-04-21 10:51:07 -0700281dev/ contains two directories char/ and block/. Inside these two
282directories there are symlinks named <major>:<minor>. These symlinks
283point to the sysfs directory for the given device. /sys/dev provides a
284quick way to lookup the sysfs interface for a device from the result of
285a stat(2) operation.
Linus Torvalds1da177e2005-04-16 15:20:36 -0700286
287More information can driver-model specific features can be found in
288Documentation/driver-model/.
289
290
291TODO: Finish this section.
292
293
294Current Interfaces
295~~~~~~~~~~~~~~~~~~
296
297The following interface layers currently exist in sysfs:
298
299
300- devices (include/linux/device.h)
301----------------------------------
302Structure:
303
304struct device_attribute {
Mike Murphyf8a1af62009-02-22 01:19:23 -0500305 struct attribute attr;
306 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
307 char *buf);
308 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
309 const char *buf, size_t count);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700310};
311
312Declaring:
313
Mike Murphyf8a1af62009-02-22 01:19:23 -0500314DEVICE_ATTR(_name, _mode, _show, _store);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700315
316Creation/Removal:
317
318int device_create_file(struct device *device, struct device_attribute * attr);
319void device_remove_file(struct device * dev, struct device_attribute * attr);
320
321
322- bus drivers (include/linux/device.h)
323--------------------------------------
324Structure:
325
326struct bus_attribute {
327 struct attribute attr;
328 ssize_t (*show)(struct bus_type *, char * buf);
329 ssize_t (*store)(struct bus_type *, const char * buf);
330};
331
332Declaring:
333
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200334BUS_ATTR(_name, _mode, _show, _store)
Linus Torvalds1da177e2005-04-16 15:20:36 -0700335
336Creation/Removal:
337
338int bus_create_file(struct bus_type *, struct bus_attribute *);
339void bus_remove_file(struct bus_type *, struct bus_attribute *);
340
341
342- device drivers (include/linux/device.h)
343-----------------------------------------
344
345Structure:
346
347struct driver_attribute {
348 struct attribute attr;
349 ssize_t (*show)(struct device_driver *, char * buf);
Mike Murphyf8a1af62009-02-22 01:19:23 -0500350 ssize_t (*store)(struct device_driver *, const char * buf,
351 size_t count);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700352};
353
354Declaring:
355
Jan Veldemanf8d825b2005-07-31 13:12:09 +0200356DRIVER_ATTR(_name, _mode, _show, _store)
Linus Torvalds1da177e2005-04-16 15:20:36 -0700357
358Creation/Removal:
359
360int driver_create_file(struct device_driver *, struct driver_attribute *);
361void driver_remove_file(struct device_driver *, struct driver_attribute *);
362
363