[cap-talk] Object Allocation

[Jonathan S. Shapiro]

On Fri, 2007-07-06 at 15:28 +0200, Neal H. Walfield wrote:

> The question that has arisen is what object do I invoke when I
> allocate, e.g., a task.  I suspect that just as an activity does not
> know how to allocate a file (which is essentially just a collection of
> basic resources), it should not know how to allocate a task.  That is,
> I don't do activity->allocate_file and neither should I do
> activity->allocate_task.

Sure you do. More precisely, you do something like:

  create_file(with-activity, in-fs)

all the time. The difference is that the activity is now made an
explicit parameter (which is good). Similarly, you write:

  create_process(activity)

These may be library routines, but that doesn't change the model that
the program is indeed requesting allocation of a resource.

The part of your design that I find puzzling is the notion that the
activity object has these as methods. I can see two reasonable designs
here:

  1. The fundamental purpose of the activity structure is the authority
     to allocate resources, in which case it DOES know how to allocate
     the various resource types -- or at least the primitive ones from
     which others may be composed.

     In this design, your activity is essentially a space bank, though
     possibly you will not choose a hierarchy of relationships.

  2. Alternatively, an activity is merely an accounting abstraction, in
     which case it must be passed to the server that knows how to
     allocate the objects.

     This is tricky, because it requires an extensible accounting
     protocol that can handle new object introduction. I've never
     seen one of these done well.

In KeyKOS/EROS/Coyotos, it is the space bank that is the resource
principal.

> But if not invoking an activity object to allocate a basic object,
> what then?  In the case of the file, a capability naming a file server
> makes sense, e.g., fs->allocate_file.  But where did this fs object
> come from?  Presumable, it was created by some file server
> factory/builder, which knows how to instantiate these types of objects
> given some more basic resources.  (And where does the factory builder
> come from...?)

You are suffering from a violation of abstraction boundaries. In a
dekernelized systems, "higher" resource abstractions are necessarily
composed from more primitive resource abstractions. The job of the
resource principal is to handle the primitive allocations, not the
composed allocations.

> For basic resources, it seems to me that there must be some sort of
> "static constructor".  The questions I have are: is this a good model;
> is this just a bootstrap problem that I should, perhaps, ignore; and,
> assuming your answers do not render the following non-sense, how does
> a task get access to the static constructor so that it can invoke the
> allocate constructor to allocate an object?

Well, as I say, I think you have re-discovered the space bank, so I
think it's a fine idea. :-)

At least in the KeyKOS/EROS/Coyotos case, there is no static
constructor. Newly allocated primitive objects arrive in a well-defined
state (all zeros or conceptual equivalent), but this state is achieved
at *destroy* time. Because the destroy operator is the one that
increments the allocation count, it is actually the destroy operator
that "constructs" the new object. The allocate operator merely
fabricates a capability to an existing object. This is initially
counterintuitive.

shap