[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why GNU Mach is so different?

From: Marcus Brinkmann
Subject: Re: Why GNU Mach is so different?
Date: Sun, 30 Dec 2001 15:15:40 +0100
User-agent: Mutt/1.3.24i

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).


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]