On Tue, 15 Apr 2014 12:30:47 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Tue, Apr 15, 2014 at 01:26:27PM +0200, Natanael Copa wrote:
> On Tue, 15 Apr 2014 10:37:40 +0100
> "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
>
> > On Tue, Apr 15, 2014 at 11:31:23AM +0200, Natanael Copa wrote:
> > > The gnulib's physmem_total will as a fallback report 64MB as total
> > > memory if sysconf(_SC_PHYS_PAGES) is unimplemented on linux. This makes
> > > it impossible to detect if physmem_total works or not, so we try first
> > > the linux only sysinfo(2) before falling back to gnulibs physmem_total.
> > >
> > > This makes the total memory be correctly reported on musl libc and
> > > uclibc.
> > >
> > > Signed-off-by: Natanael Copa <ncopa(a)alpinelinux.org>
> > > ---
> > > configure.ac | 2 +-
> > > src/nodeinfo.c | 22 ++++++++++++++++------
> > > 2 files changed, 17 insertions(+), 7 deletions(-)
> >
> > I think you should instead patch the gnulib physmem_total() function
> > to support use of sysinfo() itself. That way all the many users of
> > GNULIB will work correctly on musl/uclibc, rather than just libvirt.
>
> the intention was to fix all 3 places:
>
> * fix libvirt not trust physmem_total
> * fix gnulib to use sysinfo and fallback to sysconf
> * add _SC_PHYS_PAGES support to musl libc
>
> In any case, the gnulib's physmem_total will most likely always fall
> back to 64MB instead of fail with error since it looks like thats the
> way it is designed. I doubt they will accept fix for that.
>
> That means that libvirt cannot really trust physmem_total and IMHO it
> should be avoided.
The whole point of physmem_total is that libvirt can avoid having to
have a bunch of different implementations. Any kind of fix that libvirt
could do, can equally be done in the physmem_total, so there's no reason
to not rely on physmem_total. So we only need to fix physmem_total, and
the musl libc.
The only reason to fix libvirt, is if there's some problem that would
prevent us getting the fix into gnulib in an acceptable timeframe.
Fair enough.
I posted a bug report and a patch to bugs-gnulib.
-nc