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