bug-hurd
[Top][All Lists]
Advanced

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

Re: Gentoo GNU/Hurd thread in Gentoo Forums


From: Sergiu Ivanov
Subject: Re: Gentoo GNU/Hurd thread in Gentoo Forums
Date: Mon, 17 Nov 2008 15:34:23 +0200

On Mon, Nov 17, 2008 at 12:19 AM, massimo s. <devicerandom@gmail.com> wrote:
Sergiu Ivanov ha scritto:
>     It might be interesting to you, that it's a trial to introduce the
>     translators
>     concept to NetBSD and the final goal is to provide binary
>     compatibility with
>     GNUMach to be able to use the Hurd on top of the NetBSD kernel.
>     In case you want to ask the question "Why on a monolithic kernel?",
>     the answer
>     is that translators seem a cool thing even there.
>
>     Some things already work (but they're not yet integrated and
>     stable), you can
>     check the status on:
>     http://netbsd-soc.sourceforge.nAh, I see.
>     et/projects/hurdt/ <http://netbsd-soc.sourceforge.net/projects/hurdt/>
>
>
> Thank you for the information :-) I heard something about this, but I
> never read anything on this matter. I wonder whether Hurd community
> should feel happy about translators on NetBSD or not...

I think it should. Being a user, for me it means the Hurd running on a
*production-ready kernel*.
Sound. Up-to-date drivers. Architectures support. It is wonderful news.

Well, I wonder whether porting Hurd to NetBSD kernel would take less
effort than it should have taken to port it to L4 or Coyotos. Still,
both attempts failed, and I am strongly inclined to think that it is
just infeasible (or near infeasible) to port the Hurd on a
*monolithic* kernel, though you had better ask Hurd guys smarter than
me.

And I wonder -does it mean that a top-down approach can be taken to the
microkernel? Is it conceivable to start from the NetBSD monolithic, and
than "modularize" it piece by piece, until there is a BSDish
microkernel, NetBSD-derived but standalone drivers, and the Hurd?

I don't know whether there are specific limitations which would not
allow to so this on NetBSD kernel, but, obviously, such an operation
would mean *a lot* of work and I'd doubt that devising a brand new
microkernel will take much more :-)

Regards,
scolobb


reply via email to

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