Hi, On Tue, Jun 28, 2011 at 11:15:34PM +0200, Yann Dirson wrote: > As can be seen in your script, the use of binfmt support is not > without problems. > > + case $ARCH in > + alpha|amd64|arm|armeb|i386|m68k|mips|mipsel\ > + |powerpc|ppc64|sh4|sh4eb|sparc|sparc64) > + BINFMT_ARCH=$ARCH ;; > + armel) BINFMT_ARCH=arm ;; > + lpia) BINFMT_ARCH=i386 ;; # not yet verified FIXME > + *) echo "unknown architecture: $ARCH"; exit 1;; > + esac > > The most prominent problem IMHO is that it requires a system-wide > setting, and that in turn ties a qemu arch name to a particular > distro/ABI version. Can you elaborate where you see the problem?
> An alternative approach would be to stack another LD_PRELOAD hack, > whose job would be to wrap calls to exec calls and wrap them into a > suitable qemu invocation. > > Doing so would require careful wrapping of all those *exec*, system, > posix_spawn*; it would be tedious to take care not to break the > semantics of those library calls, and the number of such calls > suggests that more of them will likely appear, breaking things as they > appear. That is, while it is surely workable for the short term, it > looks like a costly hack, and we may want to avoid that. > > Another approach would be to intercept the execve syscall itself, > using ptrace. That would have lower dev and maintainance cost, but > higher runtime penalty. This idea was implemented in the past in > subterfugue (http://subterfugue.org/) - which would provide at least a > prototyping platform if it had not suffered from bitrot. This is > something I'm considering having a look at (I already have some old > patches addressing some of subterfugue's bitrot). I'm not sure whether you dont understand the problem that is to be solved or whether I understand how you suggest something I dont see a need to be fixed - please explain. The $ARCH variable is being set in the config file and determines for what debian architecture a multistrap is done. To figure out which qemu-*-static binary to copy in the root directory, the above lines are evaluated - how do you think that can be improved? cheers, josch -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20110629082706.GA27004@hoothoot
