Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Nov 2003 17:23:40 -0800 (PST)
From:      Ken Smith <kensmith@FreeBSD.org>
To:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   PERFORCE change 42068 for review
Message-ID:  <200311120123.hAC1NelA023263@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=42068

Change 42068 by kensmith@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311120123.hAC1NelA023263>