On Sun, Dec 30, 2001 at 04:39:03AM -0200, Ciro Cavani wrote: > 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?
Well, SMP support existed, but it was broken and unmaintained. nobody who cared enough had an SMP machine to develop it on. In oskit-mach, there is SMP support that is wholly untested and probably not finished. If you have an SMP machine, or sufficient imagination, please have a go! NORMA IPC, mmh. I saw there are #if NORMA_IPC blocks of code in gnumach. Is it sufficient to enable that, or is there indeed code missing? You might want to check it out. Again, nobody cared about it within the Hurd project to resurrect the code yet. There are some ideas about making the Hurd a distributed system (Thomas can likely tell us more about it), but so far it just didn't happen. If you are interested in putting real work into it, there are certainly things you can do. RT. The Hurd is not a real time system. It doesn't make use of RT. The Hurd runs on RT Mach, though. So you can use the real time extensions in a Hurd system, but you can't rely on the Hurd servers or the C library to do any RT'ish things for you. Are the real time changes free? We might include them by default in the future, if we find someone willing to port and maintain them. I don't understand what you mean with "ports". We have ports. BTW, I guess some stuff was disabled (SMP) when the Linux device driver glue code was integrated, and never resurrected. With oskit-mach, that part of the kernel has been cleared up again, and there is hope now to get stuff like SMP support back into our mach. > 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 think some work can be done here, not only on the kernel level (which you need), but also in the Hurd servers. I think passing ports over networks etc can be done in user space on the Hurd (and maybe should). Beside those technical features you need, there is, for example, the requirement to have a network-wide unique process id for a task. Thomas calls such a network of Hurd systems a "collective". I guess if you want to do distributed systems in a Hurdish way, collectives are the way to go. The concept exists only in Thomas head, though, so you will have to nag him a bit to tell us about his ideas. > Others thoughts that I had, are about the Corba (I read something and > nothing more), Yes, Farid has put some work into it. It is not easy to use flick for the defs files, and it is far from easy to use corba instead mig. But hey, problems are there to be solved, right? :) [I forgot what the problems were, but might be able to look it up]. > modules for devices drives (like linux); those things are > better implemented on kernel or is possible on user space? device drivers should not be made modular on the kernel level, but live in user space. oskit has all the right abstractions for that. > I know that some ideas can be wrong... All your ideas are good. You are not the first one to mention them here (you might have noticed), but you can be the first one to put real work into them (not in the sense of rewriting everything, but in the sense of integrating it in the Hurd system). Pick one or two things that interest you most and go for it! > 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... It's amazing how much interesting concepts are deeply involved in the Hurd's architecture. However, may I suggest that you grow into contributing by starting with whatever small tings there might be that annoy you? That bug fix or this additional feature, will not only make the Hurd better, but also make you more familiar with the Hurd, and give you a better feel for the whole process of contributing something. Mmmh. If you are going to learn the Hurd from ground up, you might also want to improve the documentation (mach.texi, hurd.texi). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
