filesystems/configfs/configfs.txt

20 is discovered) and it is registered with sysfs.  Its attributes then
22 readdir(3)/read(2).  It may allow some attributes to be modified via
28 mkdir(2).  It is destroyed via rmdir(2).  The attributes appear at
41 it by doing
47 subsystems.  Once a client subsystem is loaded, it will appear as a
64 When an item needs to be destroyed, remove it with rmdir(2).  An
65 item cannot be destroyed if any other item has a link to it (via
71 access remote block devices.  Call it FakeNBD.  FakeNBD uses configfs
74 the driver about it.  Here's where configfs comes in.
76 When the FakeNBD driver is loaded, it registers itself with configfs.
84 it is a uuid or a disk name:
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
148 called on it.  This initializes the reference count and sets up the
151 All users of a config_item should have a reference on it via
157 among other things.  For that, it needs a type.
199 configfs directory, it must define a configfs_attribute describing it.
200 It then adds the attribute to the NULL-terminated array
231 However, it can do more: it can create child items or groups.  This is
249 config_item (or more likely, its container structure), initializes it,
250 and returns it to configfs.  Configfs will then populate the filesystem
259 config_item, it is not necessary for a separate drop_group() method.
261 upon item allocation.  If a subsystem has no work to do, it may omit
267 (assuming that it has no children to keep it busy).  The subsystem is
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
274 down.  It no longer has a reference on its parent and has no place in
281 not drop any references here, as they still must do it in drop_item().
283 A config_group cannot be removed while it still has child items.  This
305 group via the usual group _init() functions, and it must also have
307 	When the register call returns, the subsystem is live, and it
309 the subsystem must be ready for it.
315 and configfs_example_macros.c.  It shows a trivial object displaying and
342 hierarchy, it must do so under the protection of the subsystem
346 allocated item has not been linked into this hierarchy.   Similarly, it
369 allows linking to target item, it returns 0.  A source item may wish to
370 reject a link if it only wants links to a certain type of object (say,
378 A config_item cannot be removed while it links to any other item, nor
379 can it be removed while an item links to it.  Dangling symlinks are not
385 While this could be codified by magic names in ->make_item(), it is much
405 method call notifies the subsystem the parent group is going away, it
421 configfs_depend_item() on an existing item to tell configfs that it is
424 configfs_undepend_item() on it.
428 probably shouldn't calling them of its own gumption.  Rather it should
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
434 up.  Here, the heartbeat code calls configfs_depend_item().  If it
436 If it fails, it was being torn down anyway, and heartbeat can gracefully
464 committed via rename(2).  The item is moved from a directory where it
465 can be modified to a directory where it cannot.
471 support mkdir(2) or rmdir(2) either.  It only allows rename(2).  The
474 will.  Userspace commits the item by renaming it into the "live"