Vadim Antonov's Grail

[David Jeske]

On Thu, Dec 31, 1998 at 12:54:08PM +0200, Oleg Cherevko wrote:
> I want to share ceratin resource with you as well as with Tunes & UniOS
> communities.
> 	http://www.alink.net/~avg/Grail.txt or
> 	http://www.alink.net/~avg/Grail.ps
> 

> This is a paper by Vadim Antonov (avg@alink.net,
> http://www.alink.net/~avg/) on his advanced OS architecture, called
> Grail. 

It looks like a capability based OS (with different terminiology):

http://www.cis.upenn.edu/~eros/

I appreciate the critical analysis of unix and problems with legacy
systems. However, I don't see any sweeping attempts to fix these
problems. I'd appreciate it if someone else who has read the paper
will correct me if you interpreted it different. The paper explains
using, basically, a form of redirectable shared memory as a
communication channel. Yet it specifically provides no provisions for
recording or understanding the data-format within one of these
communication channels.

>From page 14: 
> The set of all possible operations on a S-object is called the type
> of the object; the system knows nothing about the number or types of
> arguments required by each operation (earlier versions of Grail
> checked those as well, but it turned out to be rather clumsy and
> restrictive and finally was left to be implemented in user-space
> servers).  Effectively, types are sets of operation names.

Which to me means that non-specific interactions will be coded into
these objects. Tracking these types/arguments will create the same
kind of legacy problem other systems have. Does someone else read this
differently?

For example, their system call to receive a request is, from page 23:

> mtr = accept(sd, &minfo)
> 
>          struct minfo {
>               int   opnum;
>               int   nargs;
>               void  *index;
>          }

Which means the only place the 'format' of the request is stored is
inside the code of the receiver. So if I write lots of software which
talks to eachother, and I don't document the protocol well, it's going
to be a big collection of fragile software which can't be changed,
just like we have now on existing systems.

----

I do like that they realized pure-virtualization helps keep complexity
down while keeping compatibility, from page 18:

> In the Grail architecture any P-object can create S-objects
> "mimicing" any other S-objects and the internal structure of
> P-objects is entirely opaque thanks to the temporary accesses and
> impossiblity to address P-objects directly; probably the most
> interesting application of that property is that a pair of somehow
> communicating P-objects (let's call them network servers) can be
> "invisibly" inserted in the middle of any access - if the first one
> gets an access to an S-object it can tell the second to create the
> shadow S-object with exactly the same type (the first P- object can
> easily obtain and analyze its type).  After that all operations on
> the shadow S-object will generate an event in the second P-object
> which in turn will request the same (with the same name and
> arguments, that's it) operation on the original S-object.  Since the
> only kind of arguments of operations allowed by Grail is accesses
> the very same routine as described above can be applied for
> passing arguments to/from the original object's owner.

However, as I've stated above, I don't see what they've done to manage
the complexity of these interactions. Can anyone else help me out here?

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net