[coyotos-dev] Coyotos kernel update

[Valerio Bellizzomi]

On 15/04/2007, at 9.23, Jonathan S. Shapiro wrote:

>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).


I would like that Coyotos uses the Mercer-Tokuda scheduler, for two
reasons:

1. We have already talked about it on the list, and you said that you
intended to bring the EROS scheduler forward into Coyotos unchanged.
References:
- http://www.coyotos.org/pipermail/coyotos-dev/2005-November/000236.html
- http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00068.html

2. You have already a working implementation,  so you have experience with
it.

For these reasons it sounds good as default scheduler. Can you expand on
why it is complicated ?


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