Quoting Daniel P. Berrange (berrange@redhat.com):
On Wed, Sep 16, 2015 at 03:15:52PM +0000, Serge Hallyn wrote:
Quoting Fabio Kung (fabio.kung@gmail.com):
On Mon, Sep 7, 2015 at 8:55 AM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
Ah, my memory was failing me, so took a bit of searching, but
http://fabiokung.com/2014/03/13/memory-inside-linux-containers/
I can't find anything called 'libmymem', and in 2014 he said
https://github.com/docker/docker/issues/8427#issuecomment-58255159
so maybe this never went anywhere.
Correct, unfortunately.
For the same reasons you cited above, and because everyeone is rolling their own at fuse level, I still think that a libresource and patches to proc tools to use them, is the right way to go. We have no shortage of sample code for the functions doing the actual work, between libvirt, lxc, docker, etc :)
Should we just go ahead and start a libresource github project?
+1, if there's momentum on this I believe I will be able to contribute some cycles. Maybe now is the right time?
Might be. Maybe the thing to do is start a project and mailing list (any objections to github? Do we create a new project for this?), and see if more than 3 people join :) Announce on containers@ and cgroup@ mailing lists, and start discussing what a reasonable API would look like.
FWIW, I would support any such effort, but I'm unlikely to have free resources to do anything more than watch its mailing list.
NP - if you can correct our course if we're heading someplace bad for libvirt that'll be great. Though I suspect lxc/lxd and libvirt will mostly agree. Ok, so I could create a project on github, but that doesn't come with a m-l. Last I used it, sf was problematic. Any other suggestions for where to host a mailing list? Might the github issue tracker suffice? We could (as worked quite well for lxd) have a specs/ directory in a libresource source tree, and use issues and pull reuqests to guide the api specifications under that directory. Just a thought. -serge