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

[Serge Hallyn]

Quoting Daniel P. Berrange (berrange at redhat.com):
> On Thu, Sep 24, 2015 at 03:53:24PM +0000, Serge Hallyn wrote:
> > Quoting Daniel P. Berrange (berrange at redhat.com):
> > > On Thu, Sep 24, 2015 at 02:41:49PM +0000, Serge Hallyn wrote:
> > > > Quoting Fabio Kung (fabio.kung at gmail.com):
> > > > > On Wed, Sep 16, 2015 at 12:29 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > > > >
> > > > > > 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.
> > > > > 
> > > > > This all sgtm. A mailing list for design discussions + github issue
> > > > > tracker seems to be working well for many open source projects I've
> > > > > been tracking lately. Most of them are using Google Groups for their
> > > > > mailing lists.
> > > > 
> > > > Well for starters I created https://github.com/hallyn/libresource .  We
> > > > should create a real project for it but it's a start.  (I'll create an
> > > > organization if this starts to move)
> > > > 
> > > > Actually I suppose the first step would be deciding on a license.  Normally
> > > > I default to gplv2, but for this that may not be appropriate.  Apache
> > > > license?  Can be settled in an issue or pull request for a License file,
> > > > I think.
> > > 
> > > My personal preference is always LGPLv2+ for libraries, since it gives
> > > ability to use from non-open source apps, but is still copyleft. I know
> > > corporates tend to prefer non-copyleft licenses like Apache these days,
> > > but that is generally for ulterior motives like being able to do dual
> > > open/closed products.
> > 
> > I think one of the most important consumers would be procps, and this
> > wouldn't be an issue for them.  Now one of the reasons we want this is
> > so that software like databases and big java apps can check their
> > real available resources to scale - would this be an issue for them,
> > or do we think they would just link to or execute commands from
> > procps?
> 
> I guess where it could become an issue is if $BIGVENDOR wants to bundle
> a copy of the library statically with their app. Some companies are
> (irrationally) paranoid about shipping anything copyleft themselves,
> so Apache could suit that. Its a tradeoff, as it obviously lets them
> embrace & extend rather than forcing them to share improvements they
> make.

Agreed.

https://github.com/hallyn/libresource/pull/2