Lines Matching refs:the
14 configfs is a ram-based filesystem that provides the converse of
21 appear in sysfs, allowing userspace to read the attributes via
23 write(2). The important point is that the object is created and
24 destroyed in kernel, the kernel controls the lifecycle of the sysfs
30 As with sysfs, readdir(3) queries the list of items and/or attributes.
31 symlink(2) can be used to group items together. Unlike sysfs, the
32 lifetime of the representation is completely driven by userspace. The
33 kernel modules backing the items must respond to this.
35 Both sysfs and configfs can and should exist together on the same
36 system. One is not a replacement for the other.
40 configfs can be compiled as a module or into the kernel. You can access
48 subdirectory (or more than one) under /config. Like sysfs, the
52 appear at this time. readdir(3) can determine what the attributes are,
58 Like sysfs, configfs expects write(2) to store the entire buffer at
60 first read the entire file, modify the portions they wish to change, and
61 then write the entire buffer back. Attribute files have a maximum size
74 the driver about it. Here's where configfs comes in.
76 When the FakeNBD driver is loaded, it registers itself with configfs.
83 arbitrary, but likely the tool will make some use of the name. Perhaps
90 The target attribute contains the IP address of the server FakeNBD will
91 connect to. The device attribute is the device on the server.
92 Predictably, the rw attribute determines whether the connection is
99 That's it. That's all there is. Now the device is configured, via the
105 object in the subsystem. It has attributes that match values on that
106 object. configfs handles the filesystem representation of that object
107 and its attributes, allowing the subsystem to ignore all but the
111 collection of items that share the same attributes and operations.
115 A subsystem is the top level of a client module. During initialization,
116 the client module registers the subsystem with configfs, the subsystem
117 appears as a directory at the top of the configfs filesystem. A
142 structure that actually represents what the subsystem is doing. The
143 config_item portion of that structure is how the object interacts with
147 config_group, a config_item must have one of the _init() functions
148 called on it. This initializes the reference count and sets up the
152 config_item_get(), and drop the reference when they are done via
156 Usually a subsystem wants the item to display and/or store attributes,
184 allocated dynamically will need to provide the ct_item_ops->release()
185 method. This method is called when the config_item's reference count
187 the ct_item_ops->show_attribute() method. Similarly, storing a new
188 attribute value uses the store_attribute() method.
198 When a config_item wants an attribute to appear as a file in the item's
200 It then adds the attribute to the NULL-terminated array
201 config_item_type->ct_attrs. When the item appears in configfs, the
202 attribute file will appear with the configfs_attribute->ca_name
203 filename. configfs_attribute->ca_mode specifies the file permissions.
205 If an attribute is readable and the config_item provides a
207 whenever userspace asks for a read(2) on the attribute. The converse
232 accomplished via the group operations specified on the group's
247 A group creates child items by providing the
248 ct_group_ops->make_item() method. If provided, this method is called from mkdir(2) in the group's …
250 and returns it to configfs. Configfs will then populate the filesystem
251 tree to reflect the new item.
253 If the subsystem wants the child to be a group itself, the subsystem
254 provides ct_group_ops->make_group(). Everything else behaves the same,
255 using the group _init() functions on the group.
257 Finally, when userspace calls rmdir(2) on the item or group,
260 The subsystem must config_item_put() the reference that was initialized
262 the ct_group_ops->drop_item() method, and configfs will call
263 config_item_put() on the item on behalf of the subsystem.
266 is called, configfs WILL remove the item from the filesystem tree
268 responsible for responding to this. If the subsystem has references to
269 the item in other threads, the memory is safe. It may take some time
270 for the item to actually disappear from the subsystem's usage. But it
273 When drop_item() is called, the item's linkage has already been torn
275 the item hierarchy. If a client needs to do some cleanup before this
276 teardown happens, the subsystem can implement the
278 configfs has removed the item from the filesystem view but before the
284 is implemented in the configfs rmdir(2) code. ->drop_item() will not be
285 called, as the item has not been dropped. rmdir(2) will fail, as the
291 tells configfs to make the subsystem appear in the file tree.
304 configfs_register_subsystem(), the subsystem must have initialized the
305 group via the usual group _init() functions, and it must also have
306 initialized the mutex.
307 When the register call returns, the subsystem is live, and it
309 the subsystem must be ready for it.
313 The best example of these basic concepts is the simple_children
314 subsystem/group and the simple_child item in configfs_example_explicit.c
320 configfs_example_macros.c is how the attributes of the childless item
324 by explicitly defining the structures involved. Conversely
326 to define the attributes. These macros are similar to their sysfs
329 [Hierarchy Navigation and the Subsystem Mutex]
332 config_items are arranged in a hierarchy due to the fact that they
333 appear in a filesystem. A subsystem is NEVER to touch the filesystem
334 parts, but the subsystem might be interested in this hierarchy. For
335 this reason, the hierarchy is mirrored via the config_group->cg_children
338 A subsystem can navigate the cg_children list and the ci_parent pointer
339 to see the tree created by the subsystem. This can race with configfs'
340 management of the hierarchy, so configfs uses the subsystem mutex to
341 protect modifications. Whenever a subsystem wants to navigate the
342 hierarchy, it must do so under the protection of the subsystem
345 A subsystem will be prevented from acquiring the mutex while a newly
347 will not be able to acquire the mutex while a dropping item has not
349 never be NULL while the item is in configfs, and that an item will only
350 be in its parent's cg_children list for the same duration. This allows
351 a subsystem to trust ci_parent and cg_children while they hold the
356 configfs provides a simple group via the group->item parent/child
358 outside of the parent/child connection. This is implemented via
361 A config_item may provide the ct_item_ops->allow_link() and
362 ct_item_ops->drop_link() methods. If the ->allow_link() method exists,
363 symlink(2) may be called with the config_item as the source of the link.
365 symlink(2) attempt outside the configfs filesystem will be denied.
367 When symlink(2) is called, the source config_item's ->allow_link()
368 method is called with itself and a target item. If the source item
373 When unlink(2) is called on the symbolic link, the source item is
374 notified via the ->drop_link() method. Like the ->drop_item() method,
376 responsible for responding to the change.
390 automatically created inside the parent at its creation. Thus,
397 children of the parent group. If ct_group_ops->make_group() exists,
398 other child groups can be created on the parent group directly.
400 A configfs subsystem specifies default groups by filling in the
401 NULL-terminated array default_groups on the config_group structure.
402 Each group in that array is populated in the configfs tree at the same
403 time as the parent group. Similarly, they are removed at the same time
404 as the parent. No extra notification is provided. When a ->drop_item()
405 method call notifies the subsystem the parent group is going away, it
409 rmdir(2). They also are not considered when rmdir(2) on the parent
416 region item is removed with rmdir(2), the ocfs2 mount must BUG or go
423 item. When the item is no longer depended on, the client driver calls
431 How does this work? Imagine the ocfs2 mount process. When it mounts,
432 it asks for a heartbeat region item. This is done via a call into the
433 heartbeat code. Inside the heartbeat code, the region item is looked
434 up. Here, the heartbeat code calls configfs_depend_item(). If it
435 succeeds, then heartbeat knows the region is safe to give to ocfs2.
444 default values can be specified for the item's attributes such that the
446 after which the subsystem can start whatever entity this item
449 Consider the FakeNBD device from above. Without a target address *and*
450 a target device, the subsystem has no idea what block device to import.
451 The simple example assumes that the subsystem merely waits until all the
453 indeed, work, but now every attribute store must check if the attributes
454 are initialized. Every attribute store must fire off the connection if
457 Far better would be an explicit action notifying the subsystem that the
459 the subsystem to provide feedback as to whether the attributes are
467 Any group that provides the ct_group_ops->commit_item() method has
469 not work directly in the group. Instead, the group will have two
473 created in the "pending" directory. Its attributes can be modified at
474 will. Userspace commits the item by renaming it into the "live"
475 directory. At this point, the subsystem receives the ->commit_item()
476 callback. If all required attributes are filled to satisfaction, the
477 method returns zero and the item is moved to the "live" directory.
479 As rmdir(2) does not work in the "live" directory, an item must be
481 time from the "live" directory back to the "pending" one. The subsystem
482 is notified by the ct_group_ops->uncommit_object() method.