Re: [libvirt] [PATCH v2] lxc: fuse mount for /proc/cpuinfo

Quoting Daniel P. Berrange (berrange(a)redhat.com): > On Wed, Sep 16, 2015 at 03:15:52PM +0000, Serge Hallyn wrote: > > Quoting Fabio Kung (fabio.kung(a)gmail.com): > > > On Mon, Sep 7, 2015 at 8:55 AM, Serge Hallyn <serge.hallyn(a)ubuntu.com&gt; 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.