Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!uflorida!gatech!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS? (re: file systems)
Message-ID: <41814@nigel.ee.udel.edu>
Date: 16 Jan 91 06:38:29 GMT
References: <41679@nigel.ee.udel.edu> <1211@cvbnetPrime.COM> <KENW.91Jan15131820@skyler.calarc.ARC.AB.CA>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 86
Nntp-Posting-Host: snow-white.ee.udel.edu

In article <KENW.91Jan15131820@skyler.calarc.ARC.AB.CA> kenw@skyler.calarc.ARC.AB.CA (Ken Wallewein) writes:
>    [[ lots of good stuff]]
>  Seems to me what we need is an object-oriented OS.  In a sense,
>that's what record-oriented file systems are trying to give us.  Both
>approaches, however, are getting a little old.

Well put.  I can see (offhand) three ways of having a filesystem that
is unlike the traditional file systems (defined as those I am familiar
with :-):

1) An object-oriented file system. Probably requires that the base
   system be object-orientedly-programmed. 
2) A filesystem wherein everything (including user process address
   spaces) is just one big address space. Probably
   unusable.  Kind of a varient of the FORTH block system.
3) An active file system.  An object-oriented file system where each
   object (i.e., each file) is actually a running program which could
   maintain itself and modify itself asynchronously.

It looks to me like the Plan-9 filesystem is either (1) or (3), but
with a really underpowered interface to the objects. I've been thinking
along the following lines:

Each name in the address space would be able to receive asynchronous
messages.  Synchronous operations would be a special case of async
messages (send then wait) instead of how UNIX now works it. Each
message would be passed to each name in the path of the object being sent
to until that object declared that it could handle the message. For example,

The message 'status /proc/16543' would first go to "/", which would say
"I can't answer that."  Then 'proc' would get 'status 16543' and would
be able to answer the status of that process.

The message 'dir usr/joe/bin' would go to usr, which would send
'dir joe/bin' to joe, which would send 'dir bin' to bin, which would
return the directory of files in that subdir.

You get the idea so far, I'm sure.

Once the appropriate object is found, the message is sent to that object.
Since it would be nice to have composible access functions, I include
in each file a list of access functions. For example, one file might
have the following access list:

key-to-seq-converter  (user-supplied)
  handles 'rewind' 'readnext' 'readprev'
  outputs 'readbykey' 'findfirstkey' 'findnextkey'
  openinstancedata 'currentkey'
block-to-key-converter (user-supplied)
  handles 'readbykey' 'findfirstkey' 'findnextkey' 'whichkey'
      'writebykey'
  outputs 'readblock' 'writeblock'
access-control (system-supplied, reads auth info)
  handles 'changemode' 'open' 'close' 'remove'
  outputs 'open' 'close' 'remove'
  fileinstancedata 'readers=a,b,c; writers=a,d,f'
block-control (system-supplied, does I/O instructions)
  handles 'open' 'close' 'readblock' 'writeblock' 
  outputs 'allocblock'
  fileinstancedata 'slow block device for data'
allocation-control (system supplied, reads/writes quotas)
  handles 'allocblock'
  fileinstancedata 'slow block device for data'
block-control (system-supplied, does I/O instructions)
  handles 'open' 'close' 'readblock' 'writeblock' 'allocblock'
  fileinstancedata 'fast block device for keys'

Note that these access objects might even get messages through the
network, allowing (say) the keys to be stored on a different machine
that the data. Feedback from the user process (to obtain authorization
information, say) could be in the form of callback-like messages,
allowing the openning process to either supply the information (which
would need to be check for correctness in some way) or to refuse to,
lest a trojan access-control function attempt to collect all 
account names, say.  At the lowest level, there will be I/O devices
that are similar to the special devices under UNIX, which will have
privledges that would not be released to normal users. 

Anyway, I've rambled enough.  I'll be thinking about this for a few
days (in spite of the need to get real work done :-).   -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=