None of the clients you mention use a user level program to service kernel
calls [which effectively sit below the mutex that is taken].

Coda could in principle be implemented in the kernel, like they are.  From
practical perspectives that would be a disaster.

There will be a release of the 95 code for Coda that actually works in
about 6 weeks from now.  A visiting student to our group Marc Schnieder
has made good progress fixing a few bugs and implementing some missing
components.

- Peter -

On Thu, 8 Oct 1998, Shyh-Wei Luan wrote:

> Hi,
> 
> The following is some excerpts from some Coda's document (I think
> Michale Callahan wrote it) for the decription of a deadlock problem in doing
> a user-level Windows 95 port and the rationale for going with
> a DOS application implementation of most of the Coda client code.
> 
> -------------- excerpts start ----------
> "Why DOS applications??  It would seem more straightforward to
> implement the Coda client cache manager, a user level program named
> Venus, as a Win32 application.  Sadly on Windows 95 we ran into the
> following (fairly well known) problem.  When a user application calls
> a Win32 file system call, the application may acquire a mutex in a
> win16 system dll.  The request should reach the kernel, and make its
> way up to Venus.  Venus is then unable to service the request because
> it cannot grab the mutex. Deadlock results."
> --------------- excerpts end ------------
> 
> This makes me wonder how NFS and Netware clients are implemented on Windows 95.
> Did they implement the whole thing in the kernel or somehow they got a solution
> to the problem?   If so, can't Coda use the same solution?  Is the deadlock
> problem somehow unique to Coda?
> 
> Shyh-Wei Luan
> 
> --
>