View source for Kernel: vnode and vfs

IRIX’s VFS (Virtual File System) and vnode architecture is conceptually similar to many UNIX-derived systems (BSD, System V, Solaris), but with some IRIX-specific behavior layering and STREAMS integration. The vnode system provides a uniform abstraction for all filesystem objects, enabling the kernel to operate generically on files, directories, FIFOs, and devices without knowing the underlying filesystem implementation.

=== 1. Vnode: Abstract File Object ===

* Purpose: Represents an in-memory file or pseudo-file object. Every file, device, pipe, or FIFO that a process can access has a corresponding vnode.
* Key Responsibilities:
** Maintain reference counts (<code>v_count</code>) for lifecycle management.
** Track the type of file (<code>v_type</code>), device association (<code>v_rdev</code>), and filesystem association (<code>v_vfsp</code>).
** Serve as a link to behavior-specific operations (via <code>v_bh</code>).
** Integrate with streams (<code>v_stream</code>) if the object is a pipe, TTY, or socket.
** Enable VM caching, delayed writes, and buffer trees for efficient I/O.
* Comparison to Solaris:  IRIX vnodes are conceptually similar to Solaris <code>vnode_t</code>. Both provide:
** Reference counting
** Filesystem abstraction
** A behavior or operations layer
** VM caching integration  Differences: IRIX exposes <code>v_buf</code>/<code>v_dpages</code> directly for buffer/page management; Solaris tends to isolate VM caching in the <code>vnode</code>/<code>vfs</code> interface via <code>v_cache</code> and VM layers.

=== 2. Behavior Layer (BHV) ===

* Purpose: Allows vnodes to stack filesystem-specific operations on top of a generic vnode.
* Mechanism:
** Each vnode has a behavior descriptor list (<code>v_bh</code>).
** Filesystems (pipefs, efs, xfs, fifofs) insert their operations at initialization.
** Kernel vnode calls (<code>VOP_READ</code>, <code>VOP_WRITE</code>, <code>VOP_CLOSE</code>) traverse the behavior chain to find the appropriate function.
* Comparison to Solaris:  IRIX’s BHV is functionally similar to Solaris’ VOP vector and shadow vnode mechanism in layered filesystems, but IRIX’s BHV model explicitly allows multiple behaviors per vnode (stacked operations).

=== 3. VFS: Virtual Filesystem Layer ===

* Purpose: Represents a mounted filesystem in-memory, providing a global interface for:
** File lookup
** Attribute management
** Mount/unmount operations
** Import/export for NFS or network filesystems
* VFS Operations (<code>vfsops_t</code>):
** <code>mount</code> / <code>umount</code>: Mount/unmount filesystem
** <code>sync</code>: Flush dirty data
** <code>statvfs</code>: Retrieve filesystem statistics
** <code>vget</code>: Lookup vnode by inode within the filesystem
** <code>quotactl</code>: Manage quotas (if supported)
** <code>import</code>: Handle import of remote filesystem data
** <code>root</code>: Provide vnode for root of FS
** <code>reclaim</code>: Clean up filesystem-specific vnode state

<blockquote>Note: In IRIX pipefs, most of these are <code>fs_nosys</code> or dummy functions because pipefs is a pseudo-filesystem without persistent storage.</blockquote>

* Comparison to Solaris:
** Very similar to Solaris <code>vfsops_t</code>.
** Both systems separate filesystem-specific behavior (<code>vnodeops_t</code>) from filesystem-wide operations (<code>vfsops_t</code>).
** IRIX adds <code>vfs_insertbhv</code> to bind a VFS to its BHV layer, enabling layered filesystems.

=== 4. Vnode Operations (<code>vnodeops_t</code>) ===

* Purpose: Defines the operations you can perform on a vnode, such as read, write, ioctl, getattr, setattr, seek, poll, and more.
* IRIX Implementation Pattern:
** Functions take a behavior descriptor (<code>bhv_desc_t</code>) instead of the vnode directly.
** For pseudo-filesystems like pipefs, the operations implement custom logic (e.g., <code>pipe_read</code>, <code>pipe_write</code>, <code>pipe_poll</code>).
** Many operations are stubbed to <code>fs_nosys</code> or <code>fs_noerr</code> if not meaningful (e.g., <code>vop_create</code> in pipefs).
* Categories of operations:
*# File I/O: <code>read</code>, <code>write</code>, <code>ioctl</code>, <code>fsync</code>, <code>fcntl</code>
*# Attributes: <code>getattr</code>, <code>setattr</code>, <code>access</code>, <code>pathconf</code>, <code>attr_get/set</code>
*# Directory/Namespace: <code>lookup</code>, <code>create</code>, <code>remove</code>, <code>mkdir</code>, <code>rmdir</code>, <code>readdir</code>, <code>symlink</code>, <code>readlink</code>
*# Locking/Mapping: <code>rwlock</code>, <code>rwunlock</code>, <code>map</code>, <code>addmap</code>, <code>delmap</code>, <code>frlock</code>
*# Streams support: <code>strgetmsg</code>, <code>strputmsg</code>
*# Polling/Selection: <code>poll</code>, <code>select</code> integration via <code>pollhead</code>
*# Cleanup: <code>inactive</code>, <code>reclaim</code>, <code>realvp</code>, <code>cover</code>, <code>link_removed</code>
* Comparison to Solaris:
** IRIX <code>vnodeops_t</code> maps almost one-to-one to Solaris VOP functions.
** IRIX uses <code>bhv_desc_t</code> for behavior dispatch; Solaris uses direct <code>vnode_t*</code> and VOP macros.
** <code>pipefs</code> shows how pseudo-filesystems are inserted into the BHV chain.

=== 5. Lifecycle Management ===

* Reference counting (<code>v_count</code>) is used by:
** VFS, FS operations, streams, and user-level file descriptors.
* Inactive/Teardown:
** <code>vnode_inactive</code> is called when the last reference is released.
** Pseudo-filesystems clean up buffers, semaphores, SVs, and polling structures.
* Reclaim:
** <code>vop_reclaim</code> (or <code>fs_noerr</code>) allows the FS to free internal structures before the vnode memory itself is freed.
* Comparison to Solaris:
** IRIX inactive/reclaim closely mirrors Solaris, where <code>VN_RELE</code> triggers <code>VOP_INACTIVE</code> and may later call <code>VOP_RECLAIM</code>.

=== 6. Integration with Poll/Select ===

* Each vnode supporting streams or pseudo-filesystems exposes a <code>poll</code> operation (<code>pipe_poll</code> example).
* Vnode maintains pollheads (<code>pi_rpq</code>, <code>pi_wpq</code>) to manage sleeping readers/writers.
* Poll/select logic interacts directly with vnodes’ wait queues, using semaphores and SVs to wake sleeping processes.
* IRIX integrates select/poll tightly with its behavior layer: the <code>vnodeops</code> dispatch ensures the correct filesystem or pseudo-device handles events.

=== 7. Streams and Pseudo-Filesystems ===

* Vnodes can represent STREAMS objects (<code>v_stream</code>), which include pipes, ttys, sockets.
* Pseudo-filesystems like pipefs, fifofs, or STREAMS-based devices rely on vnodes for identity but do not implement persistent storage.
* Pipefs shows:
** Behavior insertion (<code>pipe_bhv</code>)
** Read/write/poll implemented at the vnode level
** Attribute, locking, and inactive handling integrated with BHV and semaphores

=== 8. Key Semantic Takeaways vs. Solaris/OpenSolaris ===
{| class="wikitable"
!Feature
!IRIX
!Solaris / OpenSolaris
!Notes
|-
|Vnode abstraction
|Generic file object
|Generic file object
|Conceptually identical
|-
|Behavior Layer
|<code>v_bh</code>, multiple behaviors
|VOP vector, shadow vnode
|IRIX allows stacking; Solaris uses layered vnode/shadow vnodes
|-
|VFS interface
|<code>vfsops_t</code>
|<code>vfsops_t</code>
|Almost identical; mount/unmount, sync, statvfs, vget
|-
|Vnode ops
|<code>vnodeops_t</code>
|<code>vnodeops_t</code>
|Nearly identical; both separate FS operations from global FS ops
|-
|Streams integration
|<code>v_stream</code>
|<code>v_stream</code> (STREAMS)
|Very similar; IRIX integrates tightly with select/poll via SVs/semaphores
|-
|Page/Buffer caching
|<code>v_dpages</code>, <code>v_buf</code>, <code>v_pc</code>
|Solaris uses <code>v_cache</code>, <code>v_pages</code>
|IRIX exposes more VM/buffer fields directly
|-
|Poll/select
|<code>pollhead</code>, <code>sv_wait_sig</code>
|<code>pollhead</code> + <code>selwait</code>
|Both implement readiness/wakeup mechanisms; IRIX uses semaphores/SV directly
|}

=== 9. Summary ===
IRIX vnode/VFS system is:

* Highly modular: behavior layers allow multiple filesystems and pseudo-filesystems to stack operations.
* Stream-aware: supports pipes, ttys, FIFOs, and sockets in a unified way.
* Poll/select integrated: readiness queues and SVs are part of each vnode.
* VM-aware: page cache, dirty pages, buffers, and delwri structures are exposed.
* Reference-counted: ensures proper lifecycle management via <code>inactive</code>/<code>reclaim</code>.
* OpenSolaris-like: almost all concepts map directly to Solaris VFS/vnode system.

== See also ==

* [[Kernel: vnode Operations]]