[cap-talk] Capability accounting
Norman Hardy
norm at cap-lore.com
Wed Jun 21 18:32:51 EDT 2006
On Jun 21, 2006, at 10:51 AM, Jed at Webstart wrote:
> At 04:57 AM 6/21/2006, Norman Hardy wrote:
>
>> On Jun 19, 2006, at 1:41 PM, Jed at Webstart wrote:
>> .........
>>> In my experience (others may and I hope do differ)
>>> (accounting) has been less well developed in capability systems. In
>>> fact I'd be quite interested to explore a thread on accounting in
>>> object capability systems if anybody else has an interest in the
>>> topic.
>>> If nobody else is interested I'd at least like to hear why not -
>>> e.g. because they believe it's a solved problem or because they
>>> believe it's intractable or otherwise not productive.
>>
>> Keykos has highly developed accounting hooks,
>> see <http://cap-lore.com/CapTheory/KK/Resource.html>.
>> It was written for a Timesharing company that charged for resources.
>> There are several features available there that are available in no
>> other system, I think.
>> They seemed to be sufficient to install an application with
>> guaranteed resources.
>> This was within the confines of one machine and indeed guaranteeing
>> resources
>> for a distributed application is much more difficult.
>
> I read through the material available via the above link.
> I'd like to ask a couple of high level questions with regard to that
> material:
Indeed I can't find a good answer to your questions on my site.
I will try to fix that. In the mean time...
> 1. Regarding deputizing use of accounted resources: Do I assume
> correctly from the description that in so far as that was done (was
> it?)
> or could be done, the idea would be for users/applications to create
> subservient (I seem to recall that was the term you used - we had a
> similar "sub" account mechanism in NLTSS) meter or space bank that
> could be given to the deputy so that it could allocate resources
> charged
> to the requesting user/application?
Yes.
> Was there some sort of textual
> or other identification information in the space banks and meters
> (we had such in our accounts, including "sub" accounts) that could
> label charges to a deputy?
There was an object whose invocation produced a new user account with
its own command language interpreter and directory of capabilities.
This invocation took the directory as an argument and that directory
typically included a sub-space bank and sub meter.
In practice there was one user who created new user accounts.
That user would create the sub-bank and sub meter for each new account.
He would retain the service keys to both the bank and meter.
A directory of users mapped user names to nodes with these keys which
allowed intervention in the user's world.
> What sort of information was written out
> in your accounting reports. FYI, everything in NLTSS was handled
> in terms of "time" (CPU time nominally, but also used for storage
> charges).
A trivial program would use the service keys to record the current and
cumulative usage.
> 2. Regarding "There is no garbage collection in Keykos ...". That's
> the same philosophy we took, really by necessity, in NLTSS.
> The attitude was that, while objects could indeed become "lost"
> (possibly no or at least no easily found instances of capabilities
> to them), they were still accounted for. Whoever was responsible
> for the account would have an incentive to clean up and destroy
> the unused but still allocated resources. We had a mechanism
> whereby the owner of an account could produce new capabilities
> for objects being charged to the account. Such capabilities could
> be produced (reproduced one might say) and then destroyed if
> that was their appropriate fate.
We were even more strict. A space bank had the authority to
regurgitate the bits and pieces that it had provided but assembling
them back into useful would have been difficult.
There was no such order on a space-bank however.
We guaranteed to space bank users that pages and nodes
therefrom would be private, even from holders of service keys to
superior banks.
> An alternative approach that was available in NLTSS was to
> isolate the account that was being used to charge for unused
> resources (e.g. change active resources to other accounts) and
> then shut off the account, resulting in the destruction of the objects
> now no longer accounted for. While this mechanism was available,
> I don't believe it was ever used in practice.
>
>
> I'd be interested to hear what others think of these accounting
> approaches for resources accessed via capabilities. I don't
> believe a capability based system (e.g. on the Internet as with
> Widewords and YURLs) can get very far without dealing with
> the issue of accounting.
>
> If others believe such accounting mechanisms are not needed,
> I'd also be interested to hear that and their reasoning.
>
> --Jed http://www.webstart.com/jed/
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
More information about the cap-talk
mailing list