From: rajat@watson.ibm.com (Rajat Datta) Subject: Re: New feature for the filesystems. What do you think ? Date: Wed, 14 Apr 1993 16:13:49 GMT
In article <jeremy.734789195@chao> jeremy@sw.oz.au (Jeremy Fitzhardinge) writes:
>This is like something I'm currently working on. I've written a
>filesystem which is essentially a stub which communicates with a user
>process through a pair of file descriptors attached to pipes or sockets.
>It allows the user process to either completely synthesize a filesystem
>at the mountpoint, or generate it from another source.
>
> J
Sort of like the Plan 9 interface for file (or anything else) servers.
It would be neat to have something like the bind() call from Plan 9
that would let you attach a process to a particular file. All
filesystem calls to that file would be get directed to that process.
I guess streams might be another way to achieve the same thing. At
the very least this would allow user level testing of filesystem
code, and would allow one to develop a transparent networked
filesystem with little effort (in fact, whether the filesystem is
accessed from over the network or not becomes totally irrelevant).
Extensions from filesystems are also obvious. This would be a way to
get access to any device. To take an example from one of the the Plan
9 papers, you could implement a line printer daemon that mimics a
filesystem. Creating a file in that directory is the same as sending
it to the printer queue. rm removes it from the queue. ls -t prints
out the queue in the order files will be printed, etc.
Something like this would also let you establish specific access
methods for specific files. For example, if you are worried about
security and the encrypted passwords in /etc/passwd, you could bind a
process before that file. Any program now reading that file will get
the passwd records it expects, but with the passwd field stripped out.
Only properly authorized programs would be allowed to see the real
record. This would allow you to enforce an update policy for a
database file, for example, by routing everything through a single
server, and not have to rely on advisory locking.
-- rajat (rajat@watson.ibm.com)