Lines Matching refs:it

20 is discovered) and it is registered with sysfs.  Its attributes then
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
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.
193 configfs directory, it must define a configfs_attribute describing it.
225 However, it can do more: it can create child items or groups.  This is
243 config_item (or more likely, its container structure), initializes it,
244 and returns it to configfs.  Configfs will then populate the filesystem
253 config_item, it is not necessary for a separate drop_group() method.
255 upon item allocation.  If a subsystem has no work to do, it may omit
261 (assuming that it has no children to keep it busy).  The subsystem is
264 for the item to actually disappear from the subsystem's usage.  But it
275 not drop any references here, as they still must do it in drop_item().
277 A config_group cannot be removed while it still has child items.  This
299 group via the usual group _init() functions, and it must also have
301 	When the register call returns, the subsystem is live, and it
303 the subsystem must be ready for it.
326 hierarchy, it must do so under the protection of the subsystem
330 allocated item has not been linked into this hierarchy.   Similarly, it
353 allows linking to target item, it returns 0.  A source item may wish to
354 reject a link if it only wants links to a certain type of object (say,
362 A config_item cannot be removed while it links to any other item, nor
363 can it be removed while an item links to it.  Dangling symlinks are not
369 While this could be codified by magic names in ->make_item(), it is much
389 method call notifies the subsystem the parent group is going away, it
405 configfs_depend_item() on an existing item to tell configfs that it is
408 configfs_undepend_item() on it.
412 probably shouldn't calling them of its own gumption.  Rather it should
415 How does this work?  Imagine the ocfs2 mount process.  When it mounts,
416 it asks for a heartbeat region item.  This is done via a call into the
418 up.  Here, the heartbeat code calls configfs_depend_item().  If it
420 If it fails, it was being torn down anyway, and heartbeat can gracefully
448 committed via rename(2).  The item is moved from a directory where it
449 can be modified to a directory where it cannot.
458 will.  Userspace commits the item by renaming it into the "live"