**** BEGIN LOGGING AT Sat Feb 27 02:59:56 2010 Feb 27 03:42:59 Anyone around now? Feb 27 13:26:10 shoot Feb 27 13:26:24 So, we were talking about the Fuse.pm hack recently. Feb 27 13:26:34 oh yes Feb 27 13:26:35 And there was also talk about using containers to better handle other stuff in /proc Feb 27 13:26:38 my fault I believe Feb 27 13:27:50 Containers seem to address issues with some classes of access to /proc (because the instruction set that might be doing that might not match some of the contents of /proc/nnn, etc.), but not some of the base stuff (e.g. cpuinfo). The Fuse.pm hack has the opposite set of benefits and detriments. Feb 27 13:28:03 Do you see any reason why they two approaches would conflict? Feb 27 13:28:18 I haven't heard of containers Feb 27 13:28:28 point me at docs, I can think about it later Feb 27 13:28:44 Also, it was suggested that rather than using Fuse.pm, qemu should be hacked to force-produce false data without needing special configuration. Do you see any drawbacks to that? Feb 27 13:29:08 sounds like layering buggery to me Feb 27 13:29:23 and yes, I do see drawbacks Feb 27 13:29:26 http://lxc.sourceforge.net/ http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-karmic-containers/ Feb 27 13:29:34 as a VM it would be the kernels responsibility Feb 27 13:29:35 Please share :) Feb 27 13:30:15 Remember, we're not talking about full VM stuff here: just emulated userspace (chroots is my main use case, but running arbitrary-architecture code on a system is another) Feb 27 13:30:19 as an instruction set translator for one program, all the logic to deal with aliases, chroots, funny mounts etc will have to live whereever does the mounting Feb 27 13:30:43 so, fuse /is/ a filesystem and can fit into the existing mount stack Feb 27 13:31:00 doing it in qemu itself doesn't see to fit the layering, tome. Feb 27 13:35:18 That makes sense. Thanks for your input. Feb 27 13:35:45 lxc seems to live in the same place Feb 27 13:35:52 (namespaces, user isolation) Feb 27 13:36:12 so putting in lxc approx == putting in fuse, at first glance. still way cleaner than qemu :P Feb 27 13:38:23 can you enlarge on 'some classes of access to /proc (because the instruction set that might be doing that might not match some of the contents of /proc/nnn, etc.),' Feb 27 13:39:25 * persia experiments locally to provide a more informed opinion Feb 27 13:41:17 because, I'm thinking 'isn't linux32 going to have the same issues' Feb 27 13:41:47 so, lets look at what it does, figure out prior art Feb 27 13:42:43 That's a brilliant idea :) Feb 27 13:43:33 Looking at a /proc/nnnnn tree, I've confirmed my previous opinion that some of those contents are going to be architecture-dependent, and that it's easily confused by using binfmt and qemu. Feb 27 13:44:32 I'm not awake enough to think about it in depth now, but I think you've convinced me that the magic trio is qemu + lxc + personalities (although this gets kernely) Feb 27 13:44:43 persia: right, but is that a real issue or theoretical Feb 27 13:45:22 I'm definitely not awake enough. Feb 27 13:45:33 I don't know that lxc is needed or desirable here Feb 27 13:45:46 it depends on what we are /aiming/ for Feb 27 13:46:03 for now, gnight Feb 27 13:46:54 Heh. gnight. Maybe lool and ogra will have a better explanation. I know that some stuff FTBFS because of /proc inspection, but can't remember the details right now. Feb 27 13:48:02 persia: no need for lxc. just add virtual /proc files to qemu Feb 27 13:48:15 suihkulokki: lxc for a different purpose Feb 27 13:48:19 or personalities Feb 27 13:48:32 I do wish we'd advocate use of lxc instead of plain chroots to run ARM builds Feb 27 13:48:52 suihkulokki: Right, we definitely want some cpuinfo emulation Feb 27 13:49:02 suihkulokki: Do you have any interest in mono under qemu-arm? Feb 27 13:49:20 suihkulokki: I would love some tips in debugging it; it's hanging on exit right now Feb 27 13:50:04 you might want to try to get a simpler boehm gc app to work first Feb 27 13:51:04 suihkulokki: do you have pointers on this issue? Feb 27 13:51:27 suihkulokki: I tried a hello world mono app, it works as far as printing hello world, but dies on exit Feb 27 13:52:20 Well it hangs actually, two threads are in futex() and another one in sleep(); it could be related to the GC Feb 27 13:52:21 lool: Can you share more why we want lxc vs. chroots? Is there a reason we wouldn't want that for all chroots? Is this worth patching schroot to achieve? Feb 27 13:53:02 persia: it's probably equally valid for all chroot use cases Feb 27 13:53:16 persia: Problem is that people are apt-get installing stuff in these chroots Feb 27 13:53:17 suihkulokki: no need for qemu to fiddle with userspace file access; fuse is much better at that. Feb 27 13:53:31 anyhow, really going. ciao. Feb 27 13:53:57 persia: so that might kill processes from outside the chroot, or leak details such as the binfmt setup or /proc/mounts Feb 27 13:54:30 We typically want the type of abstraction which lxc provides to hide the desktop system running the container from the arm container Feb 27 13:54:46 It might actually miss binfmt abstraction though Feb 27 13:55:37 lifeless: it already fiddles. Feb 27 13:56:18 lool: In fact, the primary, secondary, and tertiary uses of schroot are likely to involve apt-get (other use cases may not). Feb 27 13:56:55 all syscalls go through qemu - anything you want to show/hide from arm processes can be done there. Feb 27 13:57:05 persia: Ack; it's ok to use lxc for pbuilder/sbuild etc., but it's not strictly required; you don't actually want to start init scripts and the like in build environents Feb 27 13:57:17 lool: Last I looked, lxc-on-ubuntu was sufficiently nontrivial that it's not something that can easily be done with scripted schroot setup. Do you know if work is being done on lxc+upstart? Feb 27 13:58:02 lool: Um, have you *looked* at the build logs? Heaps of time it ends up installing mail servers, and it very often grabs dbus (and starts it). Feb 27 13:58:13 These happen to work, but that's a coincidence. Feb 27 14:02:15 suihkulokki: that seems to describe the problem you mention http://www.mail-archive.com/qemu-devel@nongnu.org/msg08229.html Feb 27 14:04:29 suihkulokki: Do you have pointers on debugging apps running under qemu-arm? Feb 27 14:04:54 I can use gdb against qemu, but I wish there would be a way to poke at the emulated program somehow Feb 27 14:52:33 run it under gdbserver Feb 27 15:33:17 Where's the list of packages to port to thumb2 again? Feb 27 15:33:23 I'd like to strike qemu-kvm of the list Feb 27 15:38:15 https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList **** ENDING LOGGING AT Sun Feb 28 02:59:57 2010