Split Capabilities: Making Capabilities Scale
Jonathan S. Shapiro
shap@eros-os.org
Thu, 13 Jul 2000 21:08:23 -0400
> I love a hostile audience...
Oh dear. I hope not hostile.
> Where do the directories get their capabilities from?
If you hold a read-write capability to a directory you can install a (name,
cap) pair in it. Common design patterns are:
1. directory is given to you by administrator, e.g. at account creation.
2. directory is private. you get back what you put in ("Life is like a
sewer. What you get out of it depends on what you put into it." -- Tom
Lehrer)
3. directory is mutably shared, in which case you might get out what I put
in if we are the sharers.
> E-speak bounds the capabilities to the agents that use them across
restarts.
> In e-speak Beta 3.0, these capabilities can be kept in a persistent place,
> such as a file or a database.
Since agents are not persistent in E-speak, I take it that you mean to say
that E-speak binds the capabilities to the executable image from which the
agent will run when restarted. This is better than what we have now, but for
many applications it isn't good enough. There are cases where I really want
different capabilities for each instance. For example, your wallet agent vs.
my wallet agent.
> Well, I don't know about 3 years, but our VM/CMS IBM mainframe only went
> down for maintenance.... HP machines have a similar track record.
Our experience in the lab with our HP machines was dismal. I think that much
of perceived reliability is a function of load variance. If you only run a
couple of apps it's pretty easy to run them all for a long time.
> One MP/E server was found walled up in a Longs Drug Store. According to
the
> service rep, the walls had gone up 2 years before. Is that because these
> OSes don't have dynamic structures, or for some other reason?
As I recall, MP/E had very very few dynamically allocatable structures in
the kernel once the system was initialized. Here again, though, my
reliability experience with MP/E wasn't as good as this.
> Ah, but non-selective revocation doesn't need preplanning in e-speak Beta
> 2.2.
Nor in EROS/KeyKOS. You simply bump the version number on the object and all
outstanding capabilities die quietly.
By the way, I am greatly enjoying this discussion.