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>