Re: GNU Mach: in user-mode?

[Ivan Shmakov]

>>>>> Samuel Thibault <samuel.thibault@gnu.org> writes:

 >> I wonder, is there a chance of getting GNU Mach to run as an
 >> user-mode application under a different (e. g., GNU/Linux, or
 >> Mach-based GNU/Hurd itself) system?

 > Chances always exist.  Developers time, no.

        Surely.  Not quite the answer I've hoped for, though.

 >> * The time and qualification necessary to deploy one or more
 >> GNU/Linux systems on a single host using User-Mode Linux is (to my
 >> experience) significantly lower than for the other solutions (KVM,
 >> Xen)

 > For Xen I agree.  For KVM, I don't.  Building a UML image is not
 > particularly easier than building a KVM image.

        I've implied using rootstrap to build an image.  With that in
        mind, rootstrap relies on UML, so to use it one'll need UML
        anyway.

 >> known to me (indeed, two commands

        Namely, one command to build an image, and one more to start it.

 >> and a less-than-a-screen long configuration file,

 > KVM doesn't even need a configuration file, just -hda myfile

        The image builder (e. g., rootstrap, xen-tools) does.

 >> * Running User-Mode Linux doesn't imply any privileged user
 >> intervention (contrary to both KVM and Xen)

 > KVM doesn't either.

        Nevertheless, it depends on access to /dev/kvm, which is a
        privilege.  (Elsewhere, it isn't KVM anymore, but a Qemu
        instance.)

        There're more differences between UML and KVM.  Consider, e. g.,
        the inability to run KVM under KVM (while one can run UML under
        UML.)  However, what bothers me the most, is the use of hardware
        emulation, leading to:

    Hardware <-> Linux drivers <-> Hardware emulated by KVM <-> Mach drivers 
<-> Applications

        Should there be any bug in GNU Mach drivers (and there're many,
        I guess), the hosted GNU/Hurd will easily crash.  Should the
        extra parts of code be cut off the chain:

    Hardware <-> Linux drivers <-> UMM Pseudo-hardware <-> Applications

        the simplicity of the resulting solution will hopefully lead to
        less bugs and, for a lack of a better word, a more pleasant
        GNU/Hurd experience.

        IIRC, there was also a ``real memory'' issue.  Namely, KVM
        reserves a part of a physical RAM for the child system memory,
        while UML drags its mem= from virtual memory, effectively
        making swapless child systems feasible.

 >> * ... And then, what about having GNU/Mach supplied with Debian
 >> GNU/Linux, at your service and fully ready to host one or more
 >> GNU/Hurd instances you've just wished for?

 > We could build a package that just downloads the qemu image and start
 > it.

        It's of little interest to me, since that effectively means
        wasting roughly a half of CPU performance to the emulation
        (seemingly much more, when it comes to I/O.)