[Ocfs2-commits] jlbec commits r2096 - trunk/fs/configfs

[svn-commits at oss.oracle.com]

Author: jlbec
Signed-off-by: manish
Date: 2005-03-30 20:23:39 -0600 (Wed, 30 Mar 2005)
New Revision: 2096

Modified:
   trunk/fs/configfs/configfs.txt
Log:

o Change from object -> item in configfs.txt terminology

Signed-off-by: manish



Modified: trunk/fs/configfs/configfs.txt
===================================================================
--- trunk/fs/configfs/configfs.txt	2005-03-31 02:12:48 UTC (rev 2095)
+++ trunk/fs/configfs/configfs.txt	2005-03-31 02:23:39 UTC (rev 2096)
@@ -14,7 +14,7 @@
 configfs is a ram-based filesystem that provides the converse of
 sysfs's functionality.  Where sysfs is a filesystem-based view of
 kernel objects, configfs is a filesystem-based manager of kernel
-objects.
+objects, or config_items.
 
 With sysfs, an object is created in kernel (for example, when a device
 is discovered) and it is registered with sysfs.  Its attributes then
@@ -24,13 +24,13 @@
 destroyed in kernel, the kernel controls the lifecycle of the sysfs
 representation, and sysfs is merely a window on all this.
 
-A configfs object is created via an explicit userspace operation:
+A configfs config_item is created via an explicit userspace operation:
 mkdir(2).  It is destroyed via rmdir(2).  The attributes appear at
 mkdir(2) time, and can be read or modified via read(2) and write(2).
-As with sysfs, readdir(3) queries the list of objects and/or attributes.
-symlink(2) can be used to group objects together.  Unlike sysfs, the
+As with sysfs, readdir(3) queries the list of items and/or attributes.
+symlink(2) can be used to group items together.  Unlike sysfs, the
 lifetime of the representation is completely driven by userspace.  The
-kernel modules backing the objects must respond to this.
+kernel modules backing the items must respond to this.
 
 Both sysfs and configfs can and should exist together on the same
 system.  One is not a replacement for the other.
@@ -43,12 +43,12 @@
 	mount -t configfs none /config
 
 The configfs tree will be empty unless client modules are also loaded.
-These are modules that register their object types with configfs.  Once
+These are modules that register their item types with configfs.  Once
 a client module is loaded, it will appear as a subdirectory (or more
 than one) under /config.  Like sysfs, the configfs tree is always there,
 whether mounted on /config or not.
 
-An object is created via mkdir(2).  The object's attributes will also
+An item is created via mkdir(2).  The item's attributes will also
 appear at this time.  readdir(3) can determine what the attributes are,
 read(2) can query their default values, and write(2) can store new
 values.  Like sysfs, attributes should be ASCII text files, preferably
@@ -61,8 +61,8 @@
 then write the entire buffer back.  Attribute files have a maximum size
 of one page (PAGE_SIZE, 4096 on i386).
 
-When an object needs to be destroyed, remove it with rmdir(2).  An
-object cannot be destroyed if any other object has a link to it (via
+When an item needs to be destroyed, remove it with rmdir(2).  An
+item cannot be destroyed if any other item has a link to it (via
 symlink(2)).  Links can be removed via unlink(2).
 
 [Configuring FakeNBD: an Example]