Proposal: Squeak-E = Squeak x Kernel-E (was: squeak as a
Mark S. Miller
markm at caplet.com
Sun Jan 26 17:29:12 UTC 2003
At 07:14 AM 1/26/2003 Sunday, Robert Withers wrote:
>Mark, you seem to be saying that we wouldn't have to change the vm, in order
>to 'host' a capability language, and write an E-interpreter.
I'm catching up. Some of this is addressed in my previous post. To recap briefly:
You can write a Kernel-E interpreter, and I am proposing this as the place
to start, as a development strategy. The goal is indeed to change the vm,
but not I think in the way you have in mind.
>While that would be very interesting, my intension has been to transform
>squeak itself into a capability language. This would require some VM
>changes, to create opaque references, and MOP changes, to handle the fact
>that Inspectors won't be able to look inside an object.
I think it's a mistake to try to gradually evolve the one Smalltalk vm in place
into a capability vm. As long as it's a single vm, it will have to continue
running old code, which will prevent it from having the properties needed
for a capability vm. Fatal question: Would your vm support mutable class
variables? If the answer is yes, you will never have a good capability
system. If no, you break too much old code. And if you're willing to burn
the diskpacks and leave behind the old code, then there'd be even less
reason to evolve the vm incrementally.
Instead, I propose building a wholly new vm (Kernel-E) to co-exist along the
old one. Any individual behavior is coded and executes on one vm or the
other, but objects in either can call objects in the other. The Smalltalk vm
and all legacy Smalltalk code would then, from the perspective of Squeak-E,
just be a very large TCB, to be reduced in size incrementally over time by
rewriting libraries in Squeak-E according to proper capability discipline.
TCB implies you're always at risk to any of the Smalltalk code you run, just
as you are now. None of this changes that. But you can load code into the
new Kernel-E vm with impunity and immunity, enabling "mobile code", ie, safe
executable content. Eventually, you should stop loading new code into the
>My motivation in suggesting separate segments (vats), was that squeak should
>be able to host concurrent users.
Good. But separate object memories doesn't contribute much. E supports
multiple vats per JVM all in one address space.
>A vat, to my way of thinking, was an
>authenticated space, in addition to having the concurrency and persistent
I don't understand this.
> A user with certain amount of authority could create a vat, and
>be able to run with other vats in one image.
In E, the power to create a vat implies only the power to use resources and
obtain genuine non-determinism, which is interesting but not relevant to
this discussion. So present purposes, the power to create a vat may as well
be freely accessible in E. I don't see why one might want it otherwise.
>Squeak would then have a
>running system mode segment that could issue machine resource capabilities
>to the hosted users.
>If a vat is attached to a process and is this unit of
>persistence and concurrency, then it is also the unit of exception handling
You're correct on the exception handling, and thanks for pointing it out.
There are certain vat-based exception handling issues, and I often forget to
point these out.
I still don't know what authentication issue you have in mind.
> I may be confusing TCB level security (secure
>communications platform - Trusted Computer Base), with user authentication
I think so.
>If we look at every reference as a capability, then taming squeak will first
>involve taming each reference.
Think of every behavior (class) as having two method dispatch tables: the
Smalltalk one and the Squeak-E one. For a Smalltalk class, the Squeak-E
table will be a taming of the Smalltalk table.
Now, think of the two VMs as providing two different method call
instructions. The Smalltalk call dispatches according to the Smalltalk
behavior, and the Squeak-E call dispatches according to the Squeak-E table.
When a Squeak-E table contains a method written in Smalltalk, the method is
then run on the Smalltalk vm. Therefore, the one call stack has to
transition between VMs smoothly.
> If my implementation of your eventual
>sending mechanism is to have any chance of becoming a more broadly used
>feature, even if the implementation changes, then it looks like there are
>really two library issues. First, get the rest of the squeak library to
>handle asynchronous objects, and second, to make sure the library is tamed
A good topic for another day.
>How should debugging in a secure environment proceed? Certainly I don't
>want you looking inside of my objects, unless I give you that capability.
>I would want to look inside of my objects and since I own them, I should
>have acquired the MOP capability to look inside them.
A necessary issue not yet addressed by Kernel-E. What I have in mind is
based on the KeyKOS/EROS "brand" idea. More later....
>I am rereading the ode (http://www.erights.org/elib/capability/ode/index.html).
Thanks. Warms my heart!
Text by me above is hereby placed in the public domain
More information about the Squeak-dev