Quoting Paul Moore (pmo...@redhat.com): > On Thursday, December 15, 2011 09:14:11 AM Serge Hallyn wrote: > > Quoting Corey Bryant (cor...@linux.vnet.ibm.com): > > > On 12/14/2011 06:56 PM, Paul Moore wrote: > > > >On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote: > > > >>Hey Paul, > > > >> > > > >>just wondering, exactly which approache(s) are you prototyping? Are > > > >>you touching seccomp2? > > > > > > > >The decomposed approach as I felt (well, still do for that matter) > > > >that the enhanced seccomp stuff could be put to even better use in a > > > >decomposed mode of operation. > > > > > > > >However, earlier this week those of us involved in this effort were > > > >strongly discouraged (this probably isn't the best term to use, but > > > >there is a reason I'm a programmer and not an english student) from > > > >pursuing the decomposed prototype further so work on it has dropped > > > >off considerably. > > > > > > > >I still think it is worth pursuing, if for no other reason than to > > > >answer questions that right now we can only answer with educated > > > >guesses, but it is no longer my main focus. If anyone else is > > > >interested in this feel free to drop me some email and I can bring > > > >you up to speed on the current status. > > > > Thanks, Paul. I don't know for sure that I'll have time, but I'd > > definately be interested in anything you have about current status > > of that approach. On my own I would've pursued the seccomp2 way > > if only because I'll be doing the same for lxc, but if noone else > > is following up on decomposition I might take a look over break. > > And as you say, if the design ends up being maintaineable and with > > acceptable performance overhead, I have no doubt it would be well > > merged with seccomp2. > > The current status of the prototype is that it is still largely incomplete; > most of the "how do I do this?" work is done, now it is just a matter of > coding. > > I *think* I've identified all the function calls that the e1000 device > emulation makes into the core QEMU code as well as a good spot for forking, > most of the implementation is blank (lots of empty function bodies). About > the only part of the implementation that currently has any substance to it is > the pipe based message passing and the code trickery that allows us to go > from > straight functions calls to RPC/IPC. Neither have been tested yet, and the > former isn't as elegant as I would like, but at least they all compile > cleanly > ... ;) > > As I said earlier, I still plan to allocate some time to working on this, but > much less than before. I'll drop you another email, offlist, and if you've > got some interest/time in helping out you're more than welcome to join in.
Thanks, Paul. -serge