PERFORCE change 42068 for review
Ken Smith
kensmith at FreeBSD.org
Wed Nov 12 01:23:40 GMT 2003
http://perforce.freebsd.org/chv.cgi?CH=42068
Change 42068 by kensmith at kensmith_oliver.cse.buffalo.edu on 2003/11/11 17:22:58
- Beginning to expand on vnode operation descriptions.
Affected files ...
.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#7 edit
Differences ...
==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#7 (text+ko) ====
@@ -988,7 +988,7 @@
<variablelist>
<varlistentry>
- <term>create()</term>
+ <term>VOP_CREATE()</term>
<listitem>
<para>Create a new file system object; parent directory,
name, and initial attributes are specified.</para>
@@ -998,7 +998,7 @@
<variablelist>
<varlistentry>
- <term>whiteout()</term>
+ <term>VOP_WHITEOUT()</term>
<listitem>
<para>Create or remove whiteout for a directory entry,
permitting files to be "deleted" and "undeleted" on
@@ -1011,18 +1011,19 @@
<variablelist>
<varlistentry>
- <term>mknod()</term>
+ <term>VOP_MKNOD()</term>
<listitem>
<para>Create a special device node in the file system;
name, initial protections, and device information are
- specified.</para>
+ specified. Note that block devices can be created
+ but are not used by FreeBSD.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
- <term>open()</term>
+ <term>VOP_OPEN()</term>
<listitem>
<para>Indicate and request an open on a file system
object to the file system, permitting the file system
@@ -1037,16 +1038,18 @@
<variablelist>
<varlistentry>
- <term>close()</term>
+ <term>VOP_CLOSE()</term>
<listitem>
- <para></para>
+ <para>Called when a file is closed. Actions are file system
+ dependent but may include things like updating time
+ stamps or scheduling final write operations.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
- <term>access()</term>
+ <term>VOP_ACCESS()</term>
<listitem>
<para>Request an authorization check to determine whether
a given subject credential and thread may perform a
@@ -1061,7 +1064,7 @@
<variablelist>
<varlistentry>
- <term>getattr()</term>
+ <term>VOP_GETATTR()</term>
<listitem>
<para>Retrieve an attribute structure for the file system
object; authorizing credential and thread are
@@ -1072,7 +1075,7 @@
<variablelist>
<varlistentry>
- <term>setattr()</term>
+ <term>VOP_SETATTR()</term>
<listitem>
<para>Set components of an attribute structure for the
file system object; optionally completed attributes,
@@ -1084,7 +1087,7 @@
<variablelist>
<varlistentry>
- <term>read()</term>
+ <term>VOP_READ()</term>
<listitem>
<para>Read from the file system object; read arguments,
operation flags, and authorizing credential are
@@ -1095,7 +1098,7 @@
<variablelist>
<varlistentry>
- <term>write()</term>
+ <term>VOP_WRITE()</term>
<listitem>
<para>Write to the file system object; write arguments,
operation flags, and authorizing credential are
@@ -1106,18 +1109,23 @@
<variablelist>
<varlistentry>
- <term>ioctl()</term>
+ <term>VOP_IOCTL()</term>
<listitem>
- <para></para>
+ <para>Perform an operation other than open, close, read,
+ write on a file object. Typically used on devices
+ to set device modes or perform device-specific operations
+ like ejecting a tape from a tape drive.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
- <term>poll()</term>
+ <term>VOP_POLL()</term>
<listitem>
- <para></para>
+ <para>Poll a file object to see if requested I/O operation is
+ possible. Used to help support &man.select.2; among other
+ things.</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1133,9 +1141,15 @@
<variablelist>
<varlistentry>
- <term>revoke()</term>
+ <term>VOP_REVOKE()</term>
<listitem>
- <para></para>
+ <para>Revoke access to a file object. Used to support forced
+ unmounting of filesystems without needing to
+ <quote>blindly</quote> kill off all processes with files
+ open in that filesystem. Typically file operations that
+ would modify or read from the object will fail after the
+ object is revoked but operations like &man.close.2; will
+ be allowed to succeed.</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1363,20 +1377,28 @@
<sect3 id="secarch-fsobjectprotections">
<title>File System Object Protections </title>
-<para>
-VFS generally relies on file systems to implement per-filesystem
-protections based on their own design and implementation requirements.
-access() entry point permits file system independent code to query
-file systems concerning access to an object, and will be used during
-open and new access operations, such as file execution.; file systems
-may also implement protections in other entry points.
-However, the native UNIX protection model includes object ownership,
-simple and extended DAC access controls, file flags providing additional
-protection semantics for the file owner and system operator.
-</para>
+ <para>
+ VFS generally relies on file systems to implement
+ protections based on their own design
+ and implementation requirements. For example the
+ file system support for FAT file systems needs to
+ <quote>improvise</quote> file ownership because there
+ is no way to store file ownership information in the
+ FAT file system data structures. The VOP_ACCESS(9) entry
+ point permits file system independent code to query
+ file systems concerning access to an object, and will
+ be used during &man.open.2; as well as other operations,
+ such as file execution. File systems may also implement
+ protections in other entry points, for example
+ VOP_LOOKUP(9).
+ However, the native UNIX protection model includes object
+ ownership, simple and extended DAC access controls, and file
+ flags providing additional protection semantics for the file
+ owner and system operator.</para>
+
+ <sect4 id="secarch-ufsinodeproperties">
+ <title>UFS Inode Properties</title>
-<sect4 id="secarch-ufsinodeproperties">
- <title>UFS Inode Properties</title>
<para>
In the UNIX File System (UFS), protections are generally at the
granularity of the individual file system object, represented by an
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs
mailing list