Re: Part 2: System Structure

[Pierre THIERRY]

Scribit Bas Wijnen dies 16/05/2006 hora 00:47:
> What I want to avoid is this:
> - User starts program P
> - Program P calls server S, which needs storage
> - P provides some of its storage, and makes it opaque
> - User cannot inspect and/or change his own storage, because P
>   opaquified it.
> 
> If this is a standard operation of a space bank (that is, one that you
> get access to when you create a new sub-space bank), then this is
> possible.

Whatever standard operation a sub-space bank provides, it changes
nothing about the upper space bank. If user has read/write access to it,
it won't change. If anything asks for opacity in a space bank, then
recursively each space bank in the hierarchy must accept to give away
inspect capabilities to the specified resource.

At least this was the only sensible way to operate, as I see it.

> > > If the default is to use opaque storage, then that dialog would be
> > > very annoying (popping up at every single process instantiation)
> > Why the hell should it be the default?!
> Because it is in EROS, AFAIUI.  As far as changes aren't specified I'm
> assuming the EROS implementation (as far as I know about it).

I found very few information about constructor implementation in EROS,
where did you find that opaque storage was the default for every process
instanciation?

Curiously,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature