Re: What is *difficult* with Coyotos

[William Grim]

Personally, I think the outline you have given us is good.  Also,
I personally think we should seriously consider your alternative ideas,
because in my mind, they are ideas with a lot of past experience
backing up your insights.


What I would like to get are some detailed papers about the Coyotos
design.  I could use it for this master's thesis I'm writing that
revolves around a device driver framework for what is currently known
as GNU/Hurd-L4.  If I open up google, it would probably help me
out here, but I just wanted to get my opinion out on this particular
topic.


For me, I don't have nearly as much kernel development experience as
anyone else.  In fact, it's close to zero.  For me, the Hurd
is a good way for me to get into a kernel that is manageable to think
about and a general OS design that is still evolving.  Therefore,
nothing I post is something that is backed by years of experience, but
I will try to post the best input I can.

On 10/27/05, Jonathan S. Shapiro <address@hidden> wrote:

There is a set of issues that are not problems with Coyotos per se, but
are generically challenging design issues. Coyotos has been
intentionally designed to let application developers address some of
these issues, but as a consequence the issues become hard to ignore.
Depending on your point of view, this is either a feature or a cost.

1. Storage Accountability

Coyotos just won't let you lie to yourself about who is paying for what.
It is consciously and deliberately designed to make this type of sloppy
design difficult.

This is sometimes painful, because it requires looking at certain design
patterns much more skeptically. On the other hand, Coyotos (and EROS)
provide the necessary mechanisms to solve those problems in every case
we have encountered.

This issue will intrude on the implementation of the POSIX environment
servers, but it will not intrude on POSIX applications that run in that
environment.

2. Least Privilege

Least privilege is not a "wish list" thing in Coyotos. It is the thing
that the entire structure of the system is designed to achieve and
support. This has implications for the structure of applications.
Learning to develop in this framework takes some re-thinking and
re-learning.

People who are experienced kernel and system hackers are going to have
it the hardest. They have many assumptions that they have stopped
questioning. A depressing number of these assumptions fail when the
system design requires the developer to think in terms of accountability
for resource.

POSIX makes very few demands about this, and POSIX is the architecture
that most of you know. Setting aside the question of whether POSIX is
good or bad, it is probably clear from the discussion this month that
the EROS/Coyotos approach is very alien to the architectural assumptions
of POSIX.

3. Persistence

People are going to scratch their heads about persistence for a long
time, and they are going to expect it to have major impact on how things
get built. Mostly you can just ignore it.

4. Design Emphasis

I am not convinced that this should be the design goal of Hurd, but in
the EROS/Coyotos group we have an _expression_ that we use: "it is good
enough to commit when it is good enough that you would run the code on
your (personal) pacemaker".

[I have subsequently learned that this is a terrible goal, because the
testing and design standards of pacemaker manufacturers are depressingly
bad.]

Obviously there is stuff under development that doesn't satisfy this
test. It is really a philosophy about design. Alfred is right: we *are*
paranoid in our design. We are very very good at it. We probably have
more experience at paranoid design than any other kernel group in the
world today, and it is the reason that my students are getting hired by
the most critical kernel groups all over the world.

But it isn't the usual FLOSS approach and orientation. Partly, this is
because most FLOSS developers are young and the approach requires
intensive experience and mentoring. Partly, we are just interested in
different problem domains. This is not a criticism. It is just a
description of a difference.

I don't know if this is a "problem" or not, but it is definitely going
to be a source of culture shock. I do not suggest that Hurd should be
built this way (you may wish to consider it), but the difference in
emphasis between the groups will take some getting used to.



One comment on all of the above. Marcus has listed scalability,
stability, and survivability (robustness and recoverability) as Hurd
goals. Discussion this month may have added some security goals.

These are the hardest problems anywhere in computing, and the solutions
simply cannot be found in textbooks. They don't come from hacking code.
They emerge as a consequence of disciplined design.

Because this stuff isn't in books anywhere, there are ONLY two ways to
achieve this type of discipline:

  1. Spend 30 years of your career re-discovering a fraction of it
  2. Spend some time working to learn it from a mentor (or more than
     one) and then figure out how to adapt what you have learned.

If these goals are serious, and not just PR, then this group needs an
experience mentor. I am probably not a good one, because my personality
will get in the way. I have very little tolerance for short cuts in
architecture when better ways are known. However, I am willing to make
what I know available to this community as best I can, and I have
already invited Marcus and Neal to come to Baltimore for an extended
visit to help them evaluate Coyotos.


shap



_______________________________________________
L4-hurd mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/l4-hurd

-- 
William M. Grim
Student, Souther Illinois University at Edwardsville
Unix Network Administrator, SIUE, CS. Dept.