MIPS Fast IPC Availability

[Jonathan S. Shapiro]

> Is your superfast IPC code at a point where you would share it with
> me?
>
> I plan to start on this after my sabbatical ends in seven weeks. What
> can you give me, knowing I'll use the information for profit?

Charlie:

Your intent to use commercially is no problem.  I now have in hand
assignment agreements from all of the parties who worked on this
code.  There's some minor administrivia to finish on this end, but
nothing major.

I have not yet started on the MIPS machine.  We got involved in some
active networking work that took much longer than we expected.

The current status of EROS is as follows:

I am now in the process of wiping the last two known bugs out of the
kernel. One is in the scheduler, the other in the checkpoint
logic. The scheduler bug now appears to be nailed.  The checkpoint bug
forced me to do a total rebuild on the checkpoint code.  I hope to
have it rebuilt by Friday, after which it will take me a couple of
days to make sure it works.

Following that, I plan to do a last cleaning pass on the C++ IPC path
to make sure it is tight and that one or two details get dealt with.
Nothing complex.  This is, I think, directly relevant to your work,
and should take only a few days.

Following that, I plan to reconstruct the X86 fast IPC path (the
assembler version).

I can then go one of two ways; I can focus on getting a completed X86
release out, which is where I was heading, or I can defer that and
start the MIPS port.  My guess is that a complete X86 release may be
more valuable than a partial MIPS port.  The big items in the complete
X86 release at this stage are redoing the space bank (a pain),
rewriting VCSK to cache space (simple), and tuning the page fault
path.  All of these are relevant to any MIPS implementation.

I took some time to look over the MIPS architecture a while back to
get my mind back in gear on the machine.  There are a very small
number of architecture-dependent options in the assembly path, and the
MIPS chip doesn't actually have any choices to make about them. The
C++ code will not change significantly between the two architectures.

What I can do quickly is code up a placeholder path and save area
structure that will be pretty close to right.  I can send you a note
explaining what aspects of the C++ code path are important, and which
data structures need to be colocated for reasons of cache residency.
Though the register sizes will have changed, the key variables and the
path will not.

My guess is you won't be able to borrow the code directly anyway; at
the very least your path may not want to transfer capabilities, which
is a significant mod.  Given this, having the hand-done path should
get you a lot of the way there.

If we go that route, I will then back up and do the more complete port
and get that to you as soon as feasible.  In the end, I think you'll
discover that the calling convention probably changes from the quick
job to the final job, but not much else should change.

My sense, though, is that once we get past the quick construction of a
path, the MIPS port is really only useful to you if you can exercise
it.  The fastest way to get that to happen is to finish the X86 work.

I'm happy to be as flexible on this as you need.  How would you like
to proceed from here?


shap