Path: utzoo!attcan!utgpu!watserv1!watmath!maytag!aries5!jb
From: jb@aries5.uucp
Newsgroups: comp.sys.mac.programmer
Subject: Re: File System Re-entrancy
Message-ID: <938@maytag.waterloo.edu>
Date: 1 Dec 89 15:05:26 GMT
References: <924@maytag.waterloo.edu> <1258@smurf.ira.uka.de>
Sender: daemon@maytag.waterloo.edu
Reply-To: jb@aries5.UUCP ()
Organization: Computer Systems Group, University of Waterloo
Lines: 82

In article <1258@smurf.ira.uka.de> urlichs@smurf.ira.uka.de (Matthias Urlichs) writes:
>In comp.sys.mac.programmer jb@aries5.UUCP, writes:
>< This may seem like a strange question but seeing the discussion on
>< multi-tasking, I have a related question.
>< 
>< Is there any reliable way to make the device manager re-entrant.
><  
>That should be the file manager..?
>
Yes

>< In other words if I do a PBRead() to a device driver can that device
>< driver synchronously do another PBRead() to another device driver?  
>< 
>One simple answer: No. Not even asyncronously.
>
>I assume that you want to do something like what I tried to do a few years
>back: the straight-ahead way to partition a disk would of course be to
>open a file and then write a "disk driver" which simply does PB{read,write}()
>calls on that file.
>No such luck. Apart from the obvious (the file manager queue), the file
>manager implements its own internal stack for async requests, plus state
>variables and (since HFS) two special files which make this even more complex.

Here is what I was trying to do:

At the University of Waterloo we have developed a local area network for
the Macintosh - MacJANET.  This is a disk server, that essentailly partions
one or more files on the server (called disk boxes) into volumes.  Each
user is assigned there own volume, with read/write access.  Then there
are common read/only volumes, for applications.  This way you only need
to store one copy of the application on the network.  We implemented at
the workstation a device driver that sent sector read and write calls
for the network disk to the server, and the server would then read from
the file that data, and return it to the workstation.  Aiming at
education, we spent considerable effort on ease of use, particularly in
administration of userids etc.  This implementation had one problem, it
only allowed for one person to have write only access to a network disk, 
although multiple people could have read access.

With the advent of appleshare, we wanted to provide appleshare capbabilities
within the same framework.  i.e. allow the user to access a network disk
as an appleshare volume (where an appleshare disk is a partition in the
disk box (file) on the server).  The obvious solution (to me at least) was
mount that partion of the file, as a volume on the server, and then do
file manager calls to that volume (since appleshare calls map very nicely
to file manager calls - yes Apple did this right).  This means though
that I needed a device driver for the disk  (file partition) that I mount
on the server.  This device driver will be called by the file manager,
and then subsequently wants to call the real disk driver too actually
read from the disk.  

In other words the problem became how do I write a disk device driver that
takes read/write requests and calls the real disk driver - i.e. device
manager re-entrancy?

This also had one cute side-effect that I never thought of, that if the
server is running under multi-finder all the appleshare compatible volumes
that I mount multifinder will wish to access also.  So in effect I do not
have any control over who is calling my device driver.

If what I was doing was simpler, the proposed solution of calling the
other device driver from the completion routine would work.

I have come up with a solution that works but I am interested in hearing
if my original idea is feasible and/or suggestions on how it can be done.
(By the way, since I enjoy challenges "it can't be done" I don't believe).

Jim Bruyn

P.S.  Information on MacJANET can be obtained from:

WATCOM Products
415 Phillip Street
Waterloo, Ontario
N2L 3X2

(519)-886-3700

MacJANET has other features, like print spooling, tracking number of users
running an application, limitting the number of users who can use an
application concurrently, etc.