At Sat, 19 Mar 2005 01:50:15 -0500 (EST), Ivan Jager <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
