Browse Prior Art Database

Virtual File System Triggers Architecture

IP.com Disclosure Number: IPCOM000100119D
Original Publication Date: 1990-Mar-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 2 page(s) / 93K

Publishing Venue

IBM

Related People

Owens, GL: AUTHOR

Abstract

VFS (Virtual File System) triggers architecture is a software architecture that allows multiple VFS's to coexist without interfering with each other. It is a method of solving the problem of multiple statefull and stateless VFS's coexisting in one machine.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Virtual File System Triggers Architecture

       VFS (Virtual File System) triggers architecture is a
software architecture that allows multiple VFS's to coexist without
interfering with each other.  It is a method of solving the problem
of multiple statefull and stateless VFS's coexisting in one machine.

      The basic concept is that if a VFS wants to know when someone
else is trying to do something to a file that interferes with the
VFS's plans (i.e., keep the sync mode straight), it can set a trigger
on the file's abstraction object (a la SUN vnode or AIX gnode -
herereinafter referred to as "*node").  The trigger can be on any of
the *node operations, as selected by a bit mask in the trigger
structure.  The VFS server may catch its own *node ops, if desired.

      Gnode op triggers are a method of solving the problem of
multiple statefull and stateless VFS's coexisting in one machine.
The basic concept is that if a VFS wants to know when someone else is
trying to do something to a file (i.e., gnode) that interferes with
the VFS's plans (i.e., keep the sync mode straight), it can set a
trigger on the gnode.  The trigger can be on any of the gnode
operations, as selected by a bit mask in the trigger structure.  The
VFS server may catch its own gnode ops, if desired.

      Within each gnode there are two pointers to triggering chains.
The first is a pre gnode op trigger, the second is a post gnode op
trigger.  (See structure definitions below.) This allows triggering
both before and after the gnode op.

      The following cnventions apply:
1)   Calling gnode operations instead of calling directly, i.e., (*gn
-> gn_ops -> gn_xyz) (gn, argl, ...), they are called via a gnode
calling stub, as:  GOP_XYZ (gn, argl, arg2, ...argN);
2)   Each gnode calling stub calls the trigger functions, which
performs pre-trigger testing, calls the real gnode op, then does
post-trigger testing.  (All VFS's do this to allow for
instrumentation, "raw" calling, etc.)
3)   The gnode/gnode trigger list is locked over the duration of the
gnode op by the gnode calling stub. (For now, it is exclusive; in the
future, it may be shared lock).

      (The following only applies with shared locks.)
4)   There is an exclusive lock on the gnode trigger lists so that
while a trigger is being added or removed, nobody can cau...