Re: Translucent storage: design, pros, and cons

[Jonathan S. Shapiro]

On Thu, 2007-01-11 at 21:48 +0100, Marcus Brinkmann wrote:
> ... my current impression is that if the
> decision to use Coyotos is made, the remaining issues are probably
> minor modifications, for example like the translucent space bank,
> which hopefully could also be developed by us and added.  As you say,
> you have your own commitments and it would not be reasonable from us
> to expect you to do any major changes for us at all, and you have
> totally unexpectedly (from my part) been extraordinarily forthcoming
> in that respect.

Yes. Related to this, let me attempt to say what my actual hopes are:

1. I believe that you will be able to use the kernel directly (and that
you probably should). As the "membrane" discussion should have made
clear, a kernel MAP operation isn't helping, because the policy issues
are complicated.

2. You will probably want to adopt (subject to the translucency change):

  Space Bank
  Constructor
  The "brand" concept (supports IsTypeOf?)

It is not obvious (to me) how far you will expose these to developers.
Perhaps they will only be used at low levels.

3. The driver framework -- this is something where we should be able to
collaborate very effectively, because the requirements are mostly
dictated to us by external factors (that is: by the hardware).

However, this is an area where you will likely consider changes in the
interest of "openness" and I will mostly reject them in the interest of
robustness. It is a legitimate place for deviation given our different
objectives for the two systems.

4. The login, persistence, and user session management subsystems.


When we get much above this, I suspect that the systems diverge rapidly.


shap