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

Re: Microkernel Q



After researching this, and from some responses that I have recieved
on this, I agree that it would be a rather pointless and also monumental
task to accomplish this. My time would be much better spent adding
more comments to the Mach sources and just working with them.
    And so that's what I'm doing. I do like writing C programs, but
deciphering them can be frustrating. I tend to get overwhelmed by
all the various types which are required by library functions that are
only defined in the corresponding headers. Oh well, such is life I
suppose.
    I'm currently still mucking about with the OSKit sample kernels
and mainly just trying to learn how OSKit works. Its tough to get
started on it though, and my progress has been pretty slow.

- Doug

"Niels Möller" wrote:

> I don't think rewriting any or all pieces in a different language
> would help much. I think there is some agreement that Mach is
> suboptimal, in more fundamental ways. Mach is the µ-kernel that works
> with the Hurd today. If you want to replace it, I would recommend that
> you try helping the hurd-on-l4 project.

Yes, I agree that C is going to be essential for many years to come
for system programming. After thinking about it, it is just so firmly
entrenched in the GNU OS that it would be very difficult to implement
a kernel in another language unless it provided seamless C linkage,
which Ada currently does not.

> As for language wars, I believe C is the language of choice for
> systems programming on the GNU system, and I don't think that will
> change anytime soon.
>
> Not that I want to stop you from rewriting HURD-related stuff using
> your language of choice, but I believe there are better ways to help
> moving the Hurd away from its current µ-kernel, Mach.

Mach isn't so bad, actually. It has some real strengths that we haven't
really seen the benefits from yet. I like the idea of easily forming
clusters over lan's, and I think that the multiprocessing aspects of
Mach would be really cool to see in action. Also, anything can be
optimized once it has stabilized somewhat.
    Consider also that now that Apple is using a Mach clone, we might
see some new chipsets which are very friendly to Mach.




Reply to: