Re: Mach independence
> > I am interested if you really want HURD to be independent HIRD of
> > Daemons or you are content with those mighty daemons being rather
> > herd grazed by the Mach herder forever ;-) At this time it is not
> > possible to port HURD to another microkernel without splitting its
> > code base and this makes any porting efforts meaningless. L4-HURD
> > seems to be dead for now because of this.
> Hogwash! We already know how to manage the portability--IF a
> microkernel supports the necessary features to make the Hurd work.
> It's an open question if L4 does, because the kernel has some very
> weak semantics in certain areas. But I'm certainly hopeful.
I suppose that's the point of L4. Features needed by Hurd must be
implemented in the mk abstraction layer of Hurd. Do you think there
are some areas that are not easy to be implemented efficiently on L4
> > HURD adopted many concepts from Mach. This should not be a problem
> > (lets hope) but it must not depend on exact realization of these
> > concepts (i.e. Mach API). HURD needs a thin layer (abstract wrapper)
> > over Mach (this layer would be substantially thicker for other
> > microkernels of course). This wrapper would only cover the portion of
> > Mach services that HURD often uses.
> Of course it needs such a thing, but the point is, it's *very* thin
> indeed. The ports library is already such a layer for one part of the
> system. The pager library is another layer. And so forth. Is there
> some actual place where you think we are depending on more than a
> naming issue?
If your goal is layer very similar to some subset of the Mach API
(i.e. Mach emulation in fact)
then it is only matter of writing some typedefs, constants, wrapper
putting them into a few header files and replacing all Mach stuff
Seems easy but it has to be done and I was just wondering if somebody
actually plans this or not.
Jak poslat rukou psaný text na mail? Přece faxem Panasonic!