Re: What needs doing?

[Marcus Brinkmann]

At Sat, 19 Mar 2005 14:08:14 +0100,
Marcus Brinkmann (E-Mail) wrote:
> 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.

Something even more level, although related, is IO port spaces for
L4Ka::Pistachio.  I think some other people may already work on that,
but I have seen no result so far.  The trick here is getting something
implemented that is acceptable to the L4 people, so you are aiming at
high performance and get to hack the kernel.

The way how to implement I/O spaces efficiently on the ia32
architecture is explained in some mail in the l4ka mailing list
archive, I can dig it up for you if you are interested.  There was an
implementation of something like that in an older L4 kernel (Fiasco?),
so you would not hang in the air there.

Currently, L4 just allows all tasks to access I/O ports, which is not
acceptable from a security point of view.

At the high level side, you could also tinker with exception handling.
Basically, fix up the exception handling in L4 (maybe you can press
the L4 people to push their changes into the public tree if they
already addressed that) and look into writing a user space exception
handler that can serve as a base for future implementation of the
signal handler.

Somewhat related to that: User space debugging.  I have tried to put
the remote gdb stub into our glibc, and failed.  Now, I didn't try
very hard, so maybe it's not so hard to do it properly.  (I could give
you the code here in my tree so you get an idea how this is supposed
to work).  A full-fledged debugging interface (for local debugging) is
a bigger project, but having a remote stub in an L4 task is a first
step.  Note that this depends on fixing up the exception handling in
the kernel (which doesn't seem to be too hard - I tried it for
division by zero, and it seemed to just a single line missing for that).

For debugging of multi-threaded programs, L4 needs to be changed so
that threads in the waiting state can still receive an IPC even if
they are stopped (non-intrusive stopping of a thread in an ipc
receive).  That's L4 hacking again, and may or may not fit into the
scope of your project, depending on how fast you are.  

I think all these are quite realistic projects for a couple of weeks,
and they are not trivial, even if the amount of actual code in numbers
of lines that would be written is not so big (ie, maybe a couple of
hundred).  Conceptually, they are very interesting, require a good
understanding of how the whole thing works and lead to further
opportunities.

Thanks,
Marcus