Re: What needs doing?

[Marcus Brinkmann]

At Sat, 19 Mar 2005 01:50:15 -0500 (EST),
Ivan Jager <address@hidden> wrote:
> Neal told us there were other things that do need doing, like implementing 
> the capability copying protocol (without death notifications for now), or 
> working on how to do block transfers. We think we know enough to about 
> capabilities. We decided that would be a good project. Given the 
> recent discussion on #hurd-l4 about the security issues in the current 
> capability system, we are wondering whether it would still be 
> something useful to do. (Because if we are going to have a capability 
> server, the protocol would be completely different, I think.)

Bad timing.  I am currently in an in-depth thinking process about the
whole capability system, and come rapidly to the conclusion that we
are barkin up the wrong tree.  There are also important developments
in the L4 area which will require a shift (basically, a move away from
global thread IDs to various "spaces" like thread spaces and spaces of
communication end points).  This is currently work in progress, but
very much needed (and in fact, depending on what the final solution
will be, may still need further tinkering).

So, given that this is currently under enormous flux, if you need
something that is already specified, this is not for you ;)

> Basically our problem is that we have 6 more weeks till the end of the 
> semester, and we are back to needing something to implement. So we have a 
> few questions: Would it still be useful to implement the capability 
> transfer protocol described in ipc.tex? If not, is there anything else 
> we can work on, that has a fairly well defined spec, and would actually be 
> useful?

Well, it all depends.  Because developing the new capability system
will require some time (and will depend on a version of L4 that is not
released or even finally specified yet), implementing an transition
cap transfer protocol may still be useful, so we can keep developing
the rest of the system independently of that.  Note that the
documentation is not completely up to date on how to do it, but pretty
close.  I would not bother with the task info mess though.

Or you could go back to your original plans and write an IDE driver,
and basically limit your project to how IRQ handling works on L4.
Maybe you could play with writing an omega-like server (could be in
the same address space as the drivers), which dispatches IRQs, and
then try to get IRQ sharing to work that way and do some performance
measurements.  That's something that has to be done as well for the
device driver framework, and it is pretty independent of the
high-level abstractions we are taking too long to get right.

Some very simple kbd and serial drivers which are interrupt driven are
already in the tree, but they currently attach directly to the irq
thread, which is wrong (but then, I never intended to write a driver
framework, I just needed something that works for testing).  So, you
have a head start on how to do it, and can focus on the IRQ
dispatcher.  I think that this would be a realistic project for a six
week scope.

Thanks,
Marcus