From: Ivan Levashew <I.Levashew@bluebottle.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: User mode linux for Mac OS X with qemu
Date: Sun, 07 Jun 2009 10:19:26 +0700 [thread overview]
Message-ID: <h0fblk$gmr$1@ger.gmane.org> (raw)
In-Reply-To: <200906062233.43397.paul@codesourcery.com>
Paul Brook wrote:
>
> Doing cross emulation is in theory possible, however in practice it gets
> extremely messy for anything other than the trivial case and it's unclear
> whether it's worth the effort, or whether qemu is the appropriate place to do
> this (c.f. WINE).
>
One application of it is using Linux/Q instead of wine and java.
Another application (my dream) is deterministic build system. Community
yell loudly when OpenOffice fails to render 1:1 document from Microsoft
Office.
However, it is often unnoticed that it's insanely hard to do 1:1 build
of any randomly picked "open source" build.
Pain starts from the very beginning: configure. It requires a prefix as
part of its operation. Strange enough that it doesn't ask for command
line parameters or program launch date or whatever else parameter
unknown prior to the moment of execution.
Compilers also like putting filenames (including pathes) into binaries.
Autoconf, m4, pkg-config, lots of tools that make build result dependent
on host configuration.
Every factor commits to denying the fourth freedom, freedom to improve.
Anybody willing to fix the problem feels like an elephant in a crockery
shop. One can never be sure that he hasn't forgot some essential
compiler flag if he can't verify it. Ability to build 1:1 is the
ultimate verify. If I can build original program 1:1, I can be pretty
sure that my fix will be the only change I've maid to the compiled program.
It is often the case when I know how to fix something but not doing it
because building something is never gonna be a short journey.
A virtual machine (kinda Cygwin) might cure some of the diseases. Cygwin
is a good example here. There are no symlinks on PreVista Windows, but
Cygwin provides an illusion that they exist.
A virtual machine of my dream have a tweakable namespace (kinda Plan 9)
because it aids very much in creating a deterministic build environment.
Full-blown VM is
a) way too big gun for precise shooting
b) doesn't provide a tweakable namespace
Nix package manager is deterministic, but it takes some time to port
something into Nix. Nix puts every compiled package into dedicated
directory. Every directory needs to be mentioned in include,lib,path
lists. I think that tweaked namespace is a simpler solution.
--
If you want to get to the top, you have to start at the bottom
next prev parent reply other threads:[~2009-06-07 3:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-06 21:07 [Qemu-devel] User mode linux for Mac OS X with qemu Ivan Levashew
2009-06-06 21:33 ` Paul Brook
2009-06-07 3:19 ` Ivan Levashew [this message]
2009-06-07 20:13 ` [Qemu-devel] " François Revol
2009-06-06 22:04 ` [Qemu-devel] " Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='h0fblk$gmr$1@ger.gmane.org' \
--to=i.levashew@bluebottle.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).