[cap-talk] Evlan presentation slides

[Jed at Webstart]

At 08:42 PM 10/5/2006, Kenton Varda wrote:
>On 10/5/06, Jed at Webstart 
><<mailto:donnelley1 at webstart.com>donnelley1 at webstart.com> wrote:
>I (and I expect others) would be interested to hear how you got involved
>with Evlan and where you anticipate that work leading you and it.
>
>It's a long story, but here's a summary...
>
>At one point I was writing a game engine in C++....  At the moment 
>I'm trying to get some more real-word experience before I actually 
>attempt this.  (I'm currently working at Google, though I developed 
>Evlan before coming to Google.)

Thanks for sharing that history.  It helps to put your Evlan work 
into perspective.

>Regarding persistence:
>
>So far Evlan's implementation of persistence is pretty 
>straightforward.  Since it's a functional language and uses a 
>generational garbage collector, most of the work of actually 
>obtaining incremental snapshots of the VM state becomes very 
>easy.  My server takes a snapshot every six hours, though it could 
>easy do so more often if needed.  Each snapshot only records the 
>data which has changed since the last one, making it pretty 
>efficient.  New data is appended to the end of the snapshot, so it's 
>possible to load any snapshot in the server's history at any 
>time.  Though, in practice I manually back up and clear the whole 
>file periodically when it gets too big.
>
>As far as I/O goes, when Evlan restores from a snapshot, it simply 
>treats all open network connections as if they had been 
>reset.  Currently the only large application written in Evlan is a 
>web server, and for a web server this strategy works fine, since it 
>expects connections to be flakey and mostly stateless.  But, clearly 
>the problem will be more complicated for other kinds of software.  I 
>haven't thought much about this yet.  Thanks for sharing your 
>thoughts on the subject.

I can see this persistence discussion could go on for a while.  Not 
an email topic I think.

>On the topic of "No filesystem" - I wonder why that?
>
>Clearly everyone needs a way to organize their stuff.  But, in an 
>entirely Evlan world, filesystems would be implemented as user 
>applications, not a core component of the OS.  It would be really 
>easy to write an application which acts as some kind of container 
>for arbitrary objects/capabilities.
>
>The cool part about this is that you could imagine people writing 
>several different kinds of container apps specialized to different 
>purposes.  For storing source code, a heirarchical approach is 
>great.  But, for storing music, I prefer something more like a 
>database table that lets me sort by title, artist, etc. and quickly 
>search for the stuff I want.  By decoupling the organization style 
>from the physical devices, it becomes possible to develop many kinds 
>of outlandish filesystems and even use them at the same time.

Any extendable system (e.g. as almost all capability systems have 
been) of course has this property of being able to implement a 
variety of object types, including interfaces to persistent storage - 
what might be called "file systems".  Of course in a capability 
system processes aren't user or system, they just have whatever 
privileges they are given (hopefully what they need).

I think the bottom level question about a file system isn't so much 
what the interface looks like, but where the base storage comes 
from.   Are you suggesting that your preferred approach is to use 
"process" storage (memory) of Evlan processes (I don't really know 
what I'm talking about here) for the raw storage for "files"?  What 
we found in our OS work was that we needed some sort of storage 
container for bits to use for processes in any case, so the mechanism 
that we implemented for "files" could naturally be made available to 
other processes in the system - including "user" processes.  Our 
"file server" was the program that was trusted by the disk 
driver.  The process server was trusted by the CPU driver (what we 
called the "alternator" because it provided for switching between the 
processes ready to run in the system - giving each it's allocated 
"time slice").  The process server used files to store the state of 
processes.  Other applications (for example we had a directory server 
that stored name/capability pairs) typically used files as the base 
storage unit since they weren't trusted by the disk driver.

>Under "Real World Use" you refer to the Io Community Manager and
>some Web sites.  Can you describe how Evlan is used for these
>applications?
>
>Io Community Manager
>
>   Is that "Real World Use" chart the last?  I admit I
>had some trouble viewing this set of charts.  Perhaps the exchange
>in this area could tie into my initial general question about your
>involvement with Evlan Kenton.

I didn't see an answer to my last two questions above.  That's fine - 
I just wanted to let you know I noticed.

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20061005/35ec7250/attachment.html