Lines Matching full:it
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
70 write_bin_attribute method will be invoked on the final close, therefore it is
76 When an item needs to be destroyed, remove it with rmdir(2). An
77 item cannot be destroyed if any other item has a link to it (via
83 access remote block devices. Call it FakeNBD. FakeNBD uses configfs
86 the driver about it. Here's where configfs comes in.
88 When the FakeNBD driver is loaded, it registers itself with configfs.
96 it is a uuid or a disk name:
111 That's it. That's all there is. Now the device is configured, via the
117 object in the subsystem. It has attributes that match values on that
160 called on it. This initializes the reference count and sets up the
163 All users of a config_item should have a reference on it via
169 among other things. For that, it needs a type.
206 configfs directory, it must define a configfs_attribute describing it.
207 It then adds the attribute to the NULL-terminated array
241 with it.
265 However, it can do more: it can create child items or groups. This is
283 config_item (or more likely, its container structure), initializes it,
284 and returns it to configfs. Configfs will then populate the filesystem
293 config_item, it is not necessary for a separate drop_group() method.
295 upon item allocation. If a subsystem has no work to do, it may omit
301 (assuming that it has no children to keep it busy). The subsystem is
303 the item in other threads, the memory is safe. It may take some time
304 for the item to actually disappear from the subsystem's usage. But it
308 down. It no longer has a reference on its parent and has no place in
315 not drop any references here, as they still must do it in drop_item().
317 A config_group cannot be removed while it still has child items. This
339 group via the usual group _init() functions, and it must also have
341 When the register call returns, the subsystem is live, and it
343 the subsystem must be ready for it.
349 samples/configfs/configfs_sample.c. It shows a trivial object displaying
366 hierarchy, it must do so under the protection of the subsystem
370 allocated item has not been linked into this hierarchy. Similarly, it
393 allows linking to target item, it returns 0. A source item may wish to
394 reject a link if it only wants links to a certain type of object (say,
402 A config_item cannot be removed while it links to any other item, nor
403 can it be removed while an item links to it. Dangling symlinks are not
409 While this could be codified by magic names in ->make_item(), it is much
429 method call notifies the subsystem the parent group is going away, it
445 configfs_depend_item() on an existing item to tell configfs that it is
448 configfs_undepend_item() on it.
452 probably shouldn't calling them of its own gumption. Rather it should
455 How does this work? Imagine the ocfs2 mount process. When it mounts,
456 it asks for a heartbeat region item. This is done via a call into the
458 up. Here, the heartbeat code calls configfs_depend_item(). If it
460 If it fails, it was being torn down anyway, and heartbeat can gracefully
488 committed via rename(2). The item is moved from a directory where it
489 can be modified to a directory where it cannot.
495 support mkdir(2) or rmdir(2) either. It only allows rename(2). The
498 will. Userspace commits the item by renaming it into the "live"