> Now, I am reading (and studing) all docs that I could find about CMU > Mach UX e US, OSF e Utah Mach . I read old massages from lists too and I > strange that many important stuffs in research and others implementation > (like NORMA IPC, SMP, RT, ports...) are missing in the official > distibution (CVS). Why? Will be need to develop this stuffs again? NORMA IPC Version 1 is currently only present in CMU Mach 3.0 and RTMach. RTMach itself is availabe from NTT/Keio (please look at the-hurd-links.html for the link) as a drop-in port for FreeBSD.
Support for NORMAv1 was dropped when the Open Group started to work on NORMAv2. Unfortunately, they never publicly released that code, so you'll have to study their whitepapers and try to reimplement this yourself. The question is rather if you should do so. I did quite a lot of experiments with a cluster of Mach machines running NORMAv1 with XMM; the reason being to continue the development on task migration and load distribution started by Dejan Milojicic. This proved harder that I expected in the first place and after discussing the issue of (Mach-based) distributed memory management with people working in the field; it became clear, that Mach sementics were _still_ too bloated to provide reliable TM+LD support. This was also one of the main reasons for moving research towards L4 and other lighter microkernels. Mach research seems to have "stalled" in the last, say, 5 years, and we've learned quite a lot from the Mach experiment. I wouldn't want to discourage you from diving into Mach; its just that Mach is not at the "bleeding edge" of research anymore (at least not mainstream). > I want to work with distributed systems and clusters until the finish of > my course (college). I know that many work are being done with L4, but > in my understanding, when someone say that L4 is "working in process", I > see in Mach work done with many tests, researches and results waiting to > be improved and used. I wouldn't buy the argument that Mach is finished wether L4 is WiP. RTMach for example is still being actively developed and SMP support is present and maintained in some (alas non-opensourced) Machs. OTOH, L4 is stable enough to be used for real-world experiments: Just look at the L4Linux emulation server, L4-Fiasco, L4Ka(Hazelnut), L4/MIPS etc... kernels. They are all excellent and can be used right now for experiments. The imminent release of the upcoming new L4-API (Version 4) will also contribute to help boost L4-based development further. If you're really interested in clusters, distributed shared memory, transparent cluster-wide IPC, task migration, load distribution, crash resilience and recovery etc..., you may be much better served by using L4 rather than Mach: IPC ist more reliable, since it's not buffered by the kernel (think of crash-recovery of single nodes w.r.t. checkpointing); NORMA-like semantics can be implemented in user-land IPC servers, memory management was always (as in Mach) the domain of user-land pagers, schedulers can also be user-land,... More important though is the small amount of task/thread state that needs to be transferred in the case of task migration. Without ports redirection and all this having to be done in the kernel... More on this, if you're interested. > Others thoughts that I had, are about the Corba (I read something and > nothing more), modules for devices drives (like linux); those things are > better implemented on kernel or is possible on user space? Regarding CORBA: The only part of it that we'll need in the Hurd right now, is a good IDL stub generator that could replace MIG. The path right now looks like we're needing to switch to flick IDL compiler and change the *.defs with *.idl(s). Then, we could use e.g. DICE or IDL4 to generate stubs for L4 instead of Mach. Other CORBA stuff looks currently like unnecessary overhead to me. The dream of uKernel developers is of course to move device drivers outside the ukernel. The idea is to have user-land device driver tasks that will serve interrupts etc... on the one side and requests from an OS entity on the other side. You _can_ write device drivers in userland, both for Mach and for L4 (it's easier for L4). The point is not, that you can do so, but if you could cannibalize e.g. the large Linux driver codebase. One effort to do this was the OSKit which you should really examine more closly. The OSKit is being used both in the oskit-mach effort as well as in the L4 community. Another approach is (still-to-be-released) L4Env environment, where it should be possible to drop the source code of Linux drivers into a framework so that it integrates in the L4 user-land tasks. > I know that some ideas can be wrong... after some mounths trying > contribute to GNU/Hurd, I concluded that more study about OS is > necessary before I try something.... but I keep trying... Happy hacking! > valeu > cavani -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
