Re: Status of Coyotos

[Jonathan S. Shapiro]

Well, I promised an update without looking at the time first. Silly me,
because I need to get home, but let me get this out quickly.

The IA32 kernel got far enough that I needed a test runtime image to go
any further. This forced me into looking at "mkimage", which was a mess.

The mkimage from EROS needed a lot of changes:

  1. It needed to be a clean language so that humans could use it.
  2. It needed to handle more object types. Processes are now first
     class, FCRBs are new, and so forth.
  3. It needed a proper module system.

At the same time, it needed to generate an analyzable result, so the
language needed to be constrained carefully. This eventually ruled out
using any existing scripting language. Also, I would have needed to add
capabilities as a new value type in the existing scripting language,
which is quite hard to do in most of them. Since a good scripting
language was a useful thing to have in general, I took a long time
getting my head around that in detail. I won't be using one for mkimage,
but at least I know what I want for Coyotos scripting now.

Those watching in the last few days will have noticed intermittent
commits in the ccs/nmkimage/ tree. Once this is finished I can go back
to the kernel (which is the plan). I expect to have some world-class
help on the kernel stuff very shortly.

Note that my time has also been going into contract negotiations, real
estate (finding offices), health care negotiations, payroll processing,
and a lot of other things that don't produce code directly but matter a
lot to the people who produce the code. It's absolutely amazing how much
time and effort it takes to set that stuff up from scratch in a state
where you haven't done it before (each state has different rules, and
small details matter).

However: I think we are back to making progress, things actually look
quite promising in ways that I will talk about shortly, and I see no
further technical impediments to getting the kernel done.

Oh. Maybe one. One mistake that I made in EROS was implementing for just
one platform. This led to a lot of machine dependencies, and Charlie
Landau has had to back a lot of those out in CapROS. I started doing
Coyotos for just IA32, but on reflection I have decided that I should
bring up the Coldfire target in parallel -- at least enough to get the
HAL specified.

This means that I'll be back-filling part of the Coldfire code before
adding new stuff to the kernel tree, but it should help us get a much
more portable system to go forward with.

I'm debating whether we should do an early version of Coyotos that does
NOT implement PATTs but uses Nodes instead. This *might* let us lift
that code from EROS directly, which would let us get something running
more quickly. On the other hand, a lot of the really early app-level
code is concerned with memory management, so that might not be a win
overall. Need to think about it.

Once the kernel is done, the other thing that Hurd needs is CapIDL. This
is something where we could use some help, actually. I'll get online
later and describe the task -- it's something that any number of people
could probably do.

Beyond that, the plan for Hurd that Marcus had been articulating
deviates in almost every respect from the plan for Coyotos. Aside from
serving as examples of how to use the kernel interface, I don't think
that you guys will even end up using our space bank. So once we have the
kernel going, it seems to me that we basically won't be in the way
anymore.

shap