On Wed, Jan 21, 2004 at 01:27:53PM +0100, Olivier Galibert wrote: > [1] streaming on syscalls, no cache management, heavy tasks, cthreads, > heavy locks...
There are certainly some issues within that scope, like cache management, which however _must_ be solved radically different in the Hurd design than in a monolithic kernel, simply because of what part of the system has what responsibility and which information to make good decisions. There are good indications that if the design we have in mind would be implemented fully that you can actually optimize programs beyond what you can achieve in a general purpose monolithic kernel model. But please note that tasks are _always_ heavy, and cthreads is just an obsolete interface (pthread is sort-of available, and there is no particular reason why Ulrich Drepper's pthread can't be ported). Heavy locks, if that refers to futex's in the kernel, then that's certainly something you would never see in the Hurd because of design paradigms. But it is not at all obvious that this is a hard reason for anything. Locks can be maintained locally in a task, shared locks with support with a trusted system service, and if you really need scheduler magic for maximum efficiency, then that could be an interesting research topic. > [2] follow what a simple read() in a C program has to do before it > returns with the results and cry If that makes you cry, then open() would probably kill you. But you should have learned very early that read() is a slow way to read from files. If you use fread, then that can make use of optimization (for example: zero copy I/O in 4 MB superpages for sequential read). It's one thing to beat on the current implementation, which is still a very good proof of concept. It's another to really understand what the important problems are and what can be done to fix this without falling back into traditional paradigms of Unix kernel programming. You have barely scratched the surface. After the initial shock you hopefully will see things shift back into perspective, and if you are interested in these topics you will find that each topic you mentioned (and many more) opens the door to endless alternatives in the design. Some people claim that Mach proved that a microkernel system is not feasible, and the obvious failure plus the continued succeess of monolithic unix kernels supports them in thinking that this is the best way. We say however that the microkernel experiment has just started with Mach, and that it just opened the door to a rich world in OS design, which is still unexplored. This is of course all vapor and hype until the real thing proves the opposite. Still, I challenge you to read hour hurd-l4 design docs and tell us in which area we will have intrinsic disadvantages in areas that matter compared with monolithical kernels. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd