I'm going to answer this in two parts: 1. What is wrong with the Coyotos kernel per se? 2. How is working with Coyotos going to be difficult?
This note is the first part. COMPLETION DELAYS 1. Coyotos isn't running yet, and there isn't much kernel code. Getting a running prototype was my main task for October, and we all know what I have been doing instead. I *must* have this done very soon in order to satisfy an outside contract. The goal is to have a working kernel before end of this calendar year. The space bank will also need to be rebuilt, but this is not conceptually difficult. Persistence is going to need a major rework, because the object store needs to be redone. but progress on building a system above Coyotos can proceed without this. There may be a PhD thesis in this for someone if anybody is interested. :-) 2. I have only two hands. My students are working on related projects, but most of these are not going to help get the prototype done. The student who would be the best choice to pair-program this with me is currently planning to leave for an internship with Hermann's group, and therefore has no time between now and when he leaves. Three people have inquired about coming to do internships or visits with us soon (you know who you are). Two are definite, and I am about to respond to the third. This will help a lot. TECHNICAL ISSUES 1. No new issues relative to EROS I am fairly confident that nothing we are introducing in Coyotos will *create* new problems (other than the need for a re-design of the persistence stuff), and some problems will be greatly reduced. Specifically, Coyotos will do much better in the small percentage of cases that involve any of - servers that manage large numbers of capabilities - multithreading - non-blocking communication Based on Eric's measurements, it looks like our expectations for PATTs will be satisfied: improved utilization, higher performance, greater expressiveness, and a somewhat simplified traversal algorithm. 2. No native select() On rare occasions it would be useful to have a select()-like operation of the form: "Here are N capabilities, let me know when the corresponding servers are ready to take a new IPC". There are security problems with this, and there are severe kernel implementation difficulties. I believe that this is also true in L4.sec. 3. Real-time scheduling issues 3.1 Choice of Scheduler We have a real-time scheduler based on the Capacity Reserve scheduler. It works, but there may be something better. If so, it is easily changed, but it needs someone who understands the issues and goals of real-time a bit better than I do. 3.2 No Priority Inheritance/Donation The idea of priority inheritance is simply broken, and we don't do it. Espen and I have a dangling discussion to complete about this. This creates an OPEN ISSUE: what should the application-level idioms be to correctly support real-time in a component system. This is not just an issue of implementation. The implementation support is actually very simple. The question is: what is the correct design? In my opinion, this is a place where the experiences of the Hurd group would help a lot in guiding us. 4. Lack of Drivers Our assumption has been that we could build a compatibility cradle for Linux drivers, and then pick off the ones we really cared about for native implementation one at a time. There are several projects that have done this, and the results have been pretty good. The Hurd group has considerable experience with this. 5. DMA There are some interactions between transparent persistence and DMA. We have a set of design patterns for this, but Neal has some real experience that we would like to learn more about. Because we do not have an extensive driver framework, we do not know how well our design patterns for DMA will mesh with the requirements of a driver compatibility cradle. If it doesn't mesh, we need to fix it anyway. These are the issues that I know about with Coyotos per se. They are substantial issues, and they deserve careful thought. I also have some fairly radical ideas about how to resolve them, but I want to hold off on those until the Hurd group has a better sense of which direction it will choose. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
