>>>>> Samuel Thibault <samuel.thiba...@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.)
