Lines Matching full:it

22 is discovered) and it is registered with sysfs.  Its attributes then
24 readdir(3)/read(2).  It may allow some attributes to be modified via
30 mkdir(2).  It is destroyed via rmdir(2).  The attributes appear at
44 it by doing::
50 subsystems.  Once a client subsystem is loaded, it will appear as a
73   write_bin_attribute method will be invoked on the final close, therefore it is
79 When an item needs to be destroyed, remove it with rmdir(2).  An
80 item cannot be destroyed if any other item has a link to it (via
87 access remote block devices.  Call it FakeNBD.  FakeNBD uses configfs
90 the driver about it.  Here's where configfs comes in.
92 When the FakeNBD driver is loaded, it registers itself with configfs.
100 it is a uuid or a disk name::
115 That's it.  That's all there is.  Now the device is configured, via the
122 object in the subsystem.  It has attributes that match values on that
168 called on it.  This initializes the reference count and sets up the
171 All users of a config_item should have a reference on it via
177 among other things.  For that, it needs a type.
220 configfs directory, it must define a configfs_attribute describing it.
221 It then adds the attribute to the NULL-terminated array
258 with it.
283 However, it can do more: it can create child items or groups.  This is
301 config_item (or more likely, its container structure), initializes it,
302 and returns it to configfs.  Configfs will then populate the filesystem
311 config_item, it is not necessary for a separate drop_group() method.
313 upon item allocation.  If a subsystem has no work to do, it may omit
320    (assuming that it has no children to keep it busy).  The subsystem is
322    the item in other threads, the memory is safe.  It may take some time
323    for the item to actually disappear from the subsystem's usage.  But it
327 down.  It no longer has a reference on its parent and has no place in
334 not drop any references here, as they still must do it in drop_item().
336 A config_group cannot be removed while it still has child items.  This
359 group via the usual group _init() functions, and it must also have
362 When the register call returns, the subsystem is live, and it
364 the subsystem must be ready for it.
371 samples/configfs/configfs_sample.c. It shows a trivial object displaying
389 hierarchy, it must do so under the protection of the subsystem
393 allocated item has not been linked into this hierarchy.   Similarly, it
417 allows linking to target item, it returns 0.  A source item may wish to
418 reject a link if it only wants links to a certain type of object (say,
426 A config_item cannot be removed while it links to any other item, nor
427 can it be removed while an item links to it.  Dangling symlinks are not
434 While this could be codified by magic names in ->make_item(), it is much
454 method call notifies the subsystem the parent group is going away, it
471 configfs_depend_item() on an existing item to tell configfs that it is
474 configfs_undepend_item() on it.
478 probably shouldn't calling them of its own gumption.  Rather it should
481 How does this work?  Imagine the ocfs2 mount process.  When it mounts,
482 it asks for a heartbeat region item.  This is done via a call into the
484 up.  Here, the heartbeat code calls configfs_depend_item().  If it
486 If it fails, it was being torn down anyway, and heartbeat can gracefully