Proposal: Squeak-E = Squeak x Kernel-E (was: squeak as a
rwithers12 at attbi.com
Sun Jan 26 17:50:22 UTC 2003
fantastic! I have a couple of questions: Do we need to provide a
capability interface to plugin code? Could this help us support
function callbacks, into the image, so we could use squeak as a shared
library to another program? Forget about my authentication
PS. Mark, I am adding handling of these three messages to the CapTP
(id -> class). Does this conflict anywhere?
at: 13 put: CapTPAvailableProtocolsMessage;
at: 14 put: CapTPSwitchProtocolMessage;
at: 15 put: CapTPAcknowledgeProtocolMessage;
On Sunday, January 26, 2003, at 12:29 PM, Mark S. Miller wrote:
> 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
> to start, as a development strategy. The goal is indeed to change the
> but not I think in the way you have in mind.
>> While that would be very interesting, my intension has been to
>> squeak itself into a capability language. This would require some VM
>> changes, to create opaque references, and MOP changes, to handle the
>> 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
> running old code, which will prevent it from having the properties
> for a capability vm. Fatal question: Would your vm support mutable
> 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
> 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
> just be a very large TCB, to be reduced in size incrementally over
> time by
> rewriting libraries in Squeak-E according to proper capability
> 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
> new Kernel-E vm with impunity and immunity, enabling "mobile code",
> ie, safe
> executable content. Eventually, you should stop loading new code into
> old VM.
>> My motivation in suggesting separate segments (vats), was that squeak
>> 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
> 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
> this discussion. So present purposes, the power to create a vat may as
> 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
>> 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
>> and authentication.
> You're correct on the exception handling, and thanks for pointing it
> 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
>> and security.
> 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:
> 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
> 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
>> feature, even if the implementation changes, then it looks like there
>> really two library issues. First, get the rest of the squeak
>> library to
>> handle asynchronous objects, and second, to make sure the library is
>> for capabilities.
> A good topic for another day.
>> How should debugging in a secure environment proceed? Certainly I
>> want you looking inside of my objects, unless I give you that
>> I would want to look inside of my objects and since I own them, I
>> 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
> Thanks. Warms my heart!
> Text by me above is hereby placed in the public domain
More information about the Squeak-dev