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

Serge Hallyn serge.hallyn at ubuntu.com
Wed Sep 16 19:29:26 UTC 2015


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




More information about the libvir-list mailing list