[03:42] <bobrown> Anyone around now?
[13:26] <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:27] <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:28] <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:29] <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:30] <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:31] <lifeless> doing it in qemu itself doesn't see to fit the layering, tome.
[13:35] <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:36] <lifeless> so putting in lxc approx == putting in fuse, at first glance. still way cleaner than qemu :P
[13:38] <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:39]  * persia experiments locally to provide a more informed opinion
[13:41] <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:42] <persia> That's a brilliant idea :)
[13:43] <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:44] <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:45] <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:46] <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:48] <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:49] <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:50] <suihkulokki> you might want to try to get a simpler boehm gc app to work first
[13:51] <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:52] <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:53] <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:54] <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:55] <suihkulokki> lifeless: it already fiddles.
[13:56] <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:57] <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:58] <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.
[14:02] <lool> suihkulokki: that seems to describe the problem you mention http://www.mail-archive.com/qemu-devel@nongnu.org/msg08229.html
[14:04] <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:52] <roxfan> run it under gdbserver
[15:33] <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:38] <lool> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList