=== bjf is now known as bjf-afk === dl9pf_ is now known as dl9pf === alecrim_ is now known as alecrim [03:42] Anyone around now? === Guest47287 is now known as NCommander [13:26] shoot [13:26] So, we were talking about the Fuse.pm hack recently. [13:26] oh yes [13:26] And there was also talk about using containers to better handle other stuff in /proc [13:26] my fault I believe [13:27] 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. [13:28] Do you see any reason why they two approaches would conflict? [13:28] I haven't heard of containers [13:28] point me at docs, I can think about it later [13:28] 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? [13:29] sounds like layering buggery to me [13:29] and yes, I do see drawbacks [13:29] http://lxc.sourceforge.net/ http://blog.bodhizazen.net/linux/lxc-configure-ubuntu-karmic-containers/ [13:29] as a VM it would be the kernels responsibility [13:29] Please share :) [13:30] 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) [13:30] 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 [13:30] so, fuse /is/ a filesystem and can fit into the existing mount stack [13:31] doing it in qemu itself doesn't see to fit the layering, tome. [13:35] That makes sense. Thanks for your input. [13:35] lxc seems to live in the same place [13:35] (namespaces, user isolation) [13:36] so putting in lxc approx == putting in fuse, at first glance. still way cleaner than qemu :P [13:38] 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.),' [13:39] * persia experiments locally to provide a more informed opinion [13:41] because, I'm thinking 'isn't linux32 going to have the same issues' [13:41] so, lets look at what it does, figure out prior art [13:42] That's a brilliant idea :) [13:43] 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. [13:44] 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) [13:44] persia: right, but is that a real issue or theoretical [13:45] I'm definitely not awake enough. [13:45] I don't know that lxc is needed or desirable here [13:45] it depends on what we are /aiming/ for [13:46] for now, gnight [13:46] 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. [13:48] persia: no need for lxc. just add virtual /proc files to qemu [13:48] suihkulokki: lxc for a different purpose [13:48] or personalities [13:48] I do wish we'd advocate use of lxc instead of plain chroots to run ARM builds [13:48] suihkulokki: Right, we definitely want some cpuinfo emulation [13:49] suihkulokki: Do you have any interest in mono under qemu-arm? [13:49] suihkulokki: I would love some tips in debugging it; it's hanging on exit right now [13:50] you might want to try to get a simpler boehm gc app to work first [13:51] suihkulokki: do you have pointers on this issue? [13:51] suihkulokki: I tried a hello world mono app, it works as far as printing hello world, but dies on exit [13:52] Well it hangs actually, two threads are in futex() and another one in sleep(); it could be related to the GC [13:52] 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? [13:53] persia: it's probably equally valid for all chroot use cases [13:53] persia: Problem is that people are apt-get installing stuff in these chroots [13:53] suihkulokki: no need for qemu to fiddle with userspace file access; fuse is much better at that. [13:53] anyhow, really going. ciao. [13:53] persia: so that might kill processes from outside the chroot, or leak details such as the binfmt setup or /proc/mounts [13:54] We typically want the type of abstraction which lxc provides to hide the desktop system running the container from the arm container [13:54] It might actually miss binfmt abstraction though [13:55] lifeless: it already fiddles. [13:56] lool: In fact, the primary, secondary, and tertiary uses of schroot are likely to involve apt-get (other use cases may not). [13:56] all syscalls go through qemu - anything you want to show/hide from arm processes can be done there. [13:57] 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 [13:57] 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? [13:58] 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). [13:58] These happen to work, but that's a coincidence. [14:02] suihkulokki: that seems to describe the problem you mention http://www.mail-archive.com/qemu-devel@nongnu.org/msg08229.html [14:04] suihkulokki: Do you have pointers on debugging apps running under qemu-arm? [14:04] I can use gdb against qemu, but I wish there would be a way to poke at the emulated program somehow [14:52] run it under gdbserver [15:33] Where's the list of packages to port to thumb2 again? [15:33] I'd like to strike qemu-kvm of the list [15:38] https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList