[coyotos-dev] Storage Objects

[Jonathan S. Shapiro]

On Tue, 2006-05-30 at 08:31 +0200, Neal H. Walfield wrote:
> I sent this message last night but I neither got a copy nor have I
> seen it appear in the message archives.  Hence, I'm resending it.
> 
> 
> 
> A GPT object contains an object ID.  The named object contains 16
> capability slots (256 bytes).  A process object also contains an
> object ID.  The named object contains a number of capability slots.
> One slot if for a schedule object, another for a page object for the
> UPCB and a thing for a cappage object for the capability registers.
> There is also normal data: the protected payload, the fault code and
> the fault info.  This totals about 200 bytes.

Actually: 16*16(cap) * 8(oid) + 4 (alloc count) = 268.

> 
> I thought a storage object was the size of a hardware page.  Since
> these objects use much less than 4kb what happens to the rest of the
> storage in the object?  Do we just not care that it is wasted because
> these objects are rare relative to data and cappages?

The layout of objects into disk storage frames is the job of the object
manager, which runs in non-persistent storage.

> Since there are only two types of objects on backing store, pages and
> cappages, how do we get both data and capabilities in a single object
> (e.g. the process)?

The assumption doesn't hold in Coyotos: the on-disk representation is
completely at the discretion of the object manager. The kernel only
knows about its interface to the object store.

You may wish to pull a copy of the Coyotos tree and look at
sys/obstore/, which is where this interface is defined.

shap