On Sat, Apr 08, 2000 at 09:54:11AM +0200, Jan Atle Ramsli wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Is gnumach/Mach 4 the micro kernel Hurd will stay with, or is there an
> > official direction for something different? (like OSkit-mach,
> > OSkit-SomethingElse, mach 3, etc.). In other words, which microkernels
OSKit mach just provides a bunch of extra services for GNU Mach. This includes
Linux 2.2.12 drivers and remote debugging via gdb in the kernel.
> > should we be studying? Which microkernels would make hurd
> > implementation easier? I see bits and pieces here and there pointing
I think that Mach is fine; at least for the moment. Why? It works,
the hurd does not (at least not in the sense that I want it to).
> > different places.
> Here I have a question, too: Since it is a 'micro'-kernel, is there any
> reason why we have to use an existing one?
No, if you want to make another one, go nuts. However, I would have to
say that there are places that need a lot more work than the microkernel
(ie see the todo lists).
> In the (relatively sparse) stuff I have read, it is said that the
> microkernel is the one place where you don't care about portability,
> because it is small, and relatively easy to reimplement.
> It sort of says: Microkernel: 386-assembler
> Servers: C++
I would tend to disagree. What literature have you read? Are you thinking
along the lines of micro implies small (or size at all)? As that is simply
not true in the common case (look at Mach, vxWorks, fiasco etc).
Microkernels provide certain services to the Operating System, ``ie, the real
kernel,'' to enforce its policies. In the hurd, we have a multi server
operating system sitting on top of, at the moment, the GNU Mach microkernel.
The microkernel provides the message passing interface and the thread/task
and virtual memory: all non-trivial jobs.
> ???
> >
> > Is there a paper/page somewhere which describes the short comings of the
> > Mach 4 and/or Mach 3 code which make it difficult/impossible to achieve
> > Hurd goals?
> What are the chances that the HURD-microkernel will be ported to another
> processor?
> Shouldn't this be optimized totally for the processor in question?
> Couldnt' we expect one for 486, 586, 686, Athlon, etc.?
This sounds like a lot of work for not addressing the bottle neck. The
real bottle neck in the hurd is the Multi-server part, not the microkernel
part, which, is often blamed.
In the hurd, we use servers or translators (depending on your context) to
do everything. Since servers sit in user space, the whole point of hurd,
and they get all of their work via messages, to do anything we need to do
a lot of context switching in and out of the kernel. Example:
An application sends a message to a server; jump into kernel. Mr. Kernel
says, is this ok to do? Hmm, I need to check with Mr. Auth server, in user
land. Back into userland, Mr Auth says that it looks ok; back into to the
kernel. Mr Kernel says, ``Mr. Server, here is a message for you;'' jump
into userland. Thank you Mr Kernel. Ok Mr. Kernel, here a message for
that application, jump in to kernel land. All done! Great. Ok, I need to
check to see if you can send this to the application, Mr Auth? Jump t
userland, yes, Mr Kernel, it is ok; jump to kernel land. Thank you for that
verification Mr Auth, Al right application, here is your request.
Note the number of context switches to get a SINGLE piece of work done.
This is SLOW. How does OSF do it? Tru64 is really fast and it runs on Mach.
Excellent questions. That is completely correct. DEC decided to use a
single server. This makes for a lot of optimizations such as executing
messages in the context of the application, and allows them to continue
to use traditional implementations such as with filesystems and other time
critical players.
> >
> Sorry to compound on someone else's questions, but there really are a
> LOT of questions for people who have not hacked HURD before, and who
> would like to be writing code as soon as possible.
>
> >From our point of view, it would be just as easy to write a new kernel
> as to learn this one :-)
That is questionable. See above.
>
> Thanks, Atle
>
-Neal
--
----------------------------------------------------------------------------
Neal Walfield [EMAIL PROTECTED]
UMass Lowell - Fox 1512 Phone: 978-934-5347
Fax: 603-415-3645
Love is the triumph of imagination over intelligence.
-- H. L. Mencken
