Re: fakechroot + qemu user emulation

[Loïc Minier <lool@dooz.org>]

On Sat, Jan 22, 2011, Roger Leigh wrote:
> Having the ability to build packages for any arbitrary architecture
> using schroot will be really sweet.  Plus, if schroot supports it,
> sbuild will automatically be able to make use of it, which means
> you'll be able to do stuff like running an m68k buildd (or whatever
> arch) on much faster e.g.  amd64 hardware.

 Yep, I agree it's really sweet!  I'd like to warn about using it as a
 buildd though:
 * qemu's CPU transparency is sometimes incomplete; there was a very
   recent effort by Peter Maydell to fix the emulation which was broken
   on a lot of instructions, but he mostly focused on real-world
   instructions, the emulation might still not be 100% complete or
   correct in future occurrences; also his patches did not yet make it
   entirely upstream, nor in Debian/Ubuntu.  I suspect different
   architectures will have differing quality levels there.
 * syscall transparency is actually really bad for a buildd: if qemu
   doesn't translate a syscall, and the build detects that, it might
   assume the arch doesn't support the syscall while real hardware
   supports it.  Or vice-versa: assume the syscall is supported because
   qmeu can actually translate it, but real kernels actually don't have
   support for it (that should not get implemented in qemu, but it might
   still happen).  These are usually qemu bugs or missing features, we'd
   need some kind of archive wide rebuild to see how many difference in
   build logs (or something like that) we get between real hardware and
   qemu-user builds/
 * a lot of things are really hard to simulate/emulate/intercept:
   /proc/cpuinfo will return the host's cpuinfo, and that's true of a
   lot of file in /proc.  /dev and /sys also come to mind.

 My feeling is that this should mostly work for non-critical pieces of
 software, like high-level userspace programs.  But it's probably not a
 good idea to build complex/advanced system libs with it, like eglibc,
 pth, coreutils etc.

 qemu machine emulation (qemu-system-arm) is however much safer for this
 (albeit also much slower); it might suffer from emulation bugs, but
 it's much harder to leak any host environment into it.

-- 
Loïc Minier