Coyotos kernel update

[Jonathan S. Shapiro]

It's time for an update on Coyotos progress.

1. The current Coyotos specification (Version 0.5+, dated April 8) is
semi-frozen. Known open issues:

  1. Need to choose a scheduler interface (soon)
  2. Need to document the persistence layer (target: v1.1)
  3. Various minor issues and refinements that we know about where the
     correct resolution should be determined by experience with
     implementation. (target v0.6)

     Examples:

      A. Re-arrangement of bit positions in various objects.
      B. Introduction of cache hints in memory capabilities
      C. Whether cached short messages should be implemented, and if
         so, whether they should be handled by a separate system call
      D. Whether all received capability arguments must go to
         registers or not.

The 0.6 specification will incorporate these changes, and will accompany
the first Coldfire version.

The 0.7 specification will accompany the first IA-32 version.

2. As of this weekend we have started a marathon kernel implementation
effort. We expect this to last several weeks, and at the end we will
have an embedded kernel for Coldfire. This kernel will NOT be optimized
(in fact, it will probably be very slow), but it will be usable and it
will implement the correct kernel interface. The release will include
MINIMAL application-level components. Probably only spacebank,
constructor, console, and keyboard.

IA-32 should follow soon (requires more work). We understand that many
of you would prefer IA-32 first. We would too, but the paying customers
want Coldfire first.

Note that version 1.0 will not officially provide persistence. The
reason is that our first deliverables are for embedded systems that do
not require persistence. Persistence will arrive in version 1.1 or 1.2.
It *may* be a compilable option for earlier versions, but no promises.


How You Can Help

There are two ways that you can help:

1. Help us choose a real-time scheduling strategy. We have looked at the
Mercer-Tokuda scheduler (capacity reserves) the Jones-Rosu scheduler
(Rialto) and the Stride scheduler. Out of these, we prefer the Rialto
scheduler (Jones-Rosu), but it is patent encumbered. The patent may not
be valid, because the scheduler mechanism was disclosed in a talk at
SOSP more than one year prior to the filing date. The problem is that we
don't have $250,000 to defend the patent lawsuit.

We like the stride scheduler, but it may not be good for multimedia. It
guarantees a share, but it does not provide a way for an application to
say "wake me up at the start of my next period" (mainly because it
doesn't have any notion of a scheduling period).

The Mercer-Tokuda scheduler was used in EROS, so we have a working
implementation (not in the main branch, but we do have one). We know how
to build it, but it's complicated.

Items you can do:

  + If there is a scheduler you think we need to look at, please let us
    know ASAP.
  + If you see a way for multimedia apps to use the stride scheduler,
    tell us what it is.


2. Try not to distract us with holy wars. Tell us what you like, tell us
why, discuss it, but please remember that we have to read the mail, and
every minute we spend reading mail is a minute that is not spent
building the kernel! Before you push "send" on an email, ask yourself if
the email really adds value to the discussion (this is a good habit for
email in general, but especially important right now).


-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC