l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Translucent storage: design, pros, and cons


From: Jonathan S. Shapiro
Subject: Re: Translucent storage: design, pros, and cons
Date: Thu, 11 Jan 2007 14:47:03 -0500

On Thu, 2007-01-11 at 12:48 +0100, Marcus Brinkmann wrote:
> there are aspects of the goals and the design where I am fairly
> confident, and aspects where I am less confident, increasingly so as I
> learn more about operating system design, from you and other people.

Me too!

> One thing that causes me problems in these discussions between you and
> me is that I often don't know if you are talking about just the kernel
> or also the user space system when refering to Coyotos.  The space
> bank in particular is logically outside the kernel and part of the
> user space operating system.  But there seem to be some complicated
> interactions between the kernel design and the way memory is organized
> in the space bank that I likely do not fully appreciate and which seem
> to conflate the issues.

This is a good technical question, and I will respond to it in a
separate message with a new subject.

> ... I am wrapping up
> my math studies in a quite unrelated field (algebra and cryptography).
> I am sorry that this leaves you waiting (as well as many other
> people), but it is how it is. ... I want to think
> about these issues top-down.... All I ask for is to be able to weave
> my own picture, and let's not preclude the result.  I have made the
> mistake
> to commit prematurely to a system design once before, disappointing
> many people.  Consider me a burnt child.

Hmm. Well, first: I definitely sympathize with the problem of competing
time demands. Second: I think it is good to do a comprehensive top-down
design so that hard questions can be asked before overwhelming effort is
made. Third: I think that you *should* weave your own picture.

I have two comments. The first about my time and the second about your
time.

The problem with my time is that it is essentially over. I understand
from what you say above that you are not ready to make a kernel choice
yet. That is your decision to make. Your potential collaborators
(including me) are also operating on time tables. Even if I wanted to
wait forever, I do not have that option. I need to make effort
commitments *now* on behalf of my company if we are going to support
HURD. If you aren't ready to make a decision, I can respect that, but I
cannot wait any longer from my side.

If Coyotos turns out to be useful to you when you get there, great, but
I need to make hard system design commitments in the next two weeks that
I will not be able to reverse later. Not your fault in any way, but that
is how it is on my end.


My second comment is more a question:

You are now pushing to finish your PhD. After this, you will discover
that the life of a gainfully employed person is (sadly) much more
constrained than the life of a student. It seems unlikely that you will
have more time after graduation than you do now. Perhaps you will find a
way to get paid for working on HURD, but at the moment I think that will
be difficult. If you want to try, I think the first thing that needs to
happen is to get the HURD objectives captured in a way that can be
explained to a naive end user (i.e. someone who might pay for it).

But my immediate question is: how realistic is it to expect that you
will have the time to resume active leadership after your PhD is
completed? If it is not, what should you do about it?

These questions have nothing to do with Coyotos and nothing to do with
me. I think what I am trying to say is: if you will never have time to
actually capture what you want for the HURD, it may be that the HURD
should not wait for you. This is something that you and the community
should decide together. I only suggest that it should not be a passive
decision that "just happens."

And since I know this is not an easy question to deal with, let me also
say that while I think it is necessary, I apologize for the necessity.

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]