Sophie: coda-doc-5.2.0-4mdk noarch

coda-doc-5.2.0-4mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE> The Venus kernel interface: Initialization and cleanup </TITLE>
 <LINK HREF="kernel-venus-protocol-7.html" REL=next>
 <LINK HREF="kernel-venus-protocol-5.html" REL=previous>
 <LINK HREF="kernel-venus-protocol.html#toc6" REL=contents>
</HEAD>
<BODY>
<A HREF="kernel-venus-protocol-7.html">Next</A>
<A HREF="kernel-venus-protocol-5.html">Previous</A>
<A HREF="kernel-venus-protocol.html#toc6">Contents</A>
<HR>
<H2><A NAME="s6">6. Initialization and cleanup </A></H2>

<P>
<P>This section gives brief hints as to desirable features for the Coda
FS Driver at startup and upon shutdown or Venus failures.  Before
entering the discussion it is useful to repeat that the Coda FS Driver
maintains the following data:
<P>
<OL>
<LI> message queues</LI>
<LI> cnodes</LI>
<LI> name cache entries</LI>
</OL>

The name cache entries are entirely private to the driver, so they can
easily be manipulated.   The message queues will generally have clear
points of initialization and destruction.  The cnodes are much more
delicate.  User processes hold reference counts in Coda filesystems
and it can be difficult to clean up the cnodes.
<P>It can expect requests through:
<OL>
<LI> the message subsystem</LI>
<LI> the VFS layer</LI>
<LI> pioctl interface</LI>
</OL>

Currently the <EM>pioctl</EM> passes through the VFS for Coda so we can
treat these similarly. 
<P>
<H2><A NAME="ss6.1">6.1 Requirements </A>
</H2>

<P>
<P>The following requirements should be accomodated:
<OL>
<LI> The message queueus should have <CODE>open</CODE> and <CODE>close</CODE>
routines.  On Unix the opening of the character devices are such
routines.  
<UL>
<LI> Before opening, no messages can be placed. </LI>
<LI> Opening will
remove any old messages still pending.  </LI>
<LI> Close will notify any sleeping
processes that their upcall cannot be completed. </LI>
<LI> Close will free all
memory allocated by the message queues.</LI>
</UL>

</LI>
<LI> At open the namecache shall be initialized to empty state. 
</LI>
<LI> Before the message queues are open, all VFS operations will
fail. Fortunately this can be achieved by making sure than mounting
the Coda filesystem cannot succeed before opening.
</LI>
<LI> After closing of the queues, no VFS operations can succeed.
Here one needs to be careful, since a few operations (lookup,
read/write, readdir) can proceed without upcalls.  These must be
explicitly blocked. 
</LI>
<LI> Upon closing the namecache shall be flushed and disabled.
</LI>
<LI> All memory held by cnodes can be freed without relying on
upcalls. 
</LI>
<LI> Unmounting the file system can be done without relying on
upcalss. 
</LI>
<LI> Mounting the Coda filesystem should fail gracefully if Venus
cannot get the <CODE>rootfid</CODE> or the attributes of the <CODE>rootfid</CODE>.
The latter is best implemented by Venus fetching these objects before
attempting to mount. 
</LI>
</OL>
<P><B>NOTE</B>  NetBSD in particular but also Linux have not implemented
the above requirements fully.  For smooth operation this needs to be
corrected. 
<P>\newpage
<HR>
<A HREF="kernel-venus-protocol-7.html">Next</A>
<A HREF="kernel-venus-protocol-5.html">Previous</A>
<A HREF="kernel-venus-protocol.html#toc6">Contents</A>
</BODY>
</HTML>