What is Wrong with Coyotos

[Jonathan S. Shapiro]

I'm going to answer this in two parts:

  1. What is wrong with the Coyotos kernel per se?
  2. How is working with Coyotos going to be difficult?

This note is the first part.

COMPLETION DELAYS

1. Coyotos isn't running yet, and there isn't much kernel code.

Getting a running prototype was my main task for October, and we all
know what I have been doing instead. I *must* have this done very soon
in order to satisfy an outside contract. The goal is to have a working
kernel before end of this calendar year.

The space bank will also need to be rebuilt, but this is not
conceptually difficult.

Persistence is going to need a major rework, because the object store
needs to be redone. but progress on building a system above Coyotos can
proceed without this. There may be a PhD thesis in this for someone if
anybody is interested. :-)

2. I have only two hands.

My students are working on related projects, but most of these are not
going to help get the prototype done. The student who would be the best
choice to pair-program this with me is currently planning to leave for
an internship with Hermann's group, and therefore has no time between
now and when he leaves.

Three people have inquired about coming to do internships or visits with
us soon (you know who you are). Two are definite, and I am about to
respond to the third. This will help a lot.


TECHNICAL ISSUES

1. No new issues relative to EROS

I am fairly confident that nothing we are introducing in Coyotos will
*create* new problems (other than the need for a re-design of the
persistence stuff), and some problems will be greatly reduced.
Specifically, Coyotos will do much better in the small percentage of
cases that involve any of

  - servers that manage large numbers of capabilities
  - multithreading
  - non-blocking communication

Based on Eric's measurements, it looks like our expectations for PATTs
will be satisfied: improved utilization, higher performance, greater
expressiveness, and a somewhat simplified traversal algorithm.

2. No native select()

On rare occasions it would be useful to have a select()-like operation
of the form: "Here are N capabilities, let me know when the
corresponding servers are ready to take a new IPC". There are security
problems with this, and there are severe kernel implementation
difficulties.

I believe that this is also true in L4.sec.

3. Real-time scheduling issues

3.1 Choice of Scheduler

We have a real-time scheduler based on the Capacity Reserve scheduler.
It works, but there may be something better. If so, it is easily
changed, but it needs someone who understands the issues and goals of
real-time a bit better than I do.

3.2 No Priority Inheritance/Donation

The idea of priority inheritance is simply broken, and we don't do it.
Espen and I have a dangling discussion to complete about this. This
creates an OPEN ISSUE: what should the application-level idioms be to
correctly support real-time in a component system.

This is not just an issue of implementation. The implementation support
is actually very simple. The question is: what is the correct design?

In my opinion, this is a place where the experiences of the Hurd group
would help a lot in guiding us.

4. Lack of Drivers

Our assumption has been that we could build a compatibility cradle for
Linux drivers, and then pick off the ones we really cared about for
native implementation one at a time. There are several projects that
have done this, and the results have been pretty good.

The Hurd group has considerable experience with this.

5. DMA

There are some interactions between transparent persistence and DMA. We
have a set of design patterns for this, but Neal has some real
experience that we would like to learn more about. Because we do not
have an extensive driver framework, we do not know how well our design
patterns for DMA will mesh with the requirements of a driver
compatibility cradle.

If it doesn't mesh, we need to fix it anyway.



These are the issues that I know about with Coyotos per se. They are
substantial issues, and they deserve careful thought. I also have some
fairly radical ideas about how to resolve them, but I want to hold off
on those until the Hurd group has a better sense of which direction it
will choose.


shap