On Tue, Sep 11, 2007 at 05:49:08PM +0100, John Levon wrote: > > I just saw an email about unsigned long and max memory fly by along with > a comment like "32-bit will never have more than 'X' Gb" ... > > This raises an obvious question: is libvirt explictly not 32/64 clean? > On Solaris we build everything 32-bit by default unless there is a > reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit > kernel, then we have a problem. Indeed. This scenario of 64-bit HV with 32-bit Dom0 userspace is entirely possible on Linux too. In PPC world its actually more efficient to use 32-bit userspace unless a particular app needs 64-bit memory addressing - most of the Fedora PPC rpms are 32-bit for this reason even on PPC64 platforms. > IMO an API should *always* use explicitly-sized integers when they > contain range or size values (or use size_t etc.). Not doing so is both > dangerous and confusing... We've got an issue with some existing APIs using 'unsigned long' for memory values in KB. This may eventually force us to implement parallel APIs for these functions taking a 'long long'. We should not introduce any new APIs which are 'unsigned long' unless we know absolutely that 32-bits is enough even on a 64-bit system. > (Xen does indeed have this problem, so we run all their tools with > native word size. Currently we always use a 32-bit libvirt for > 'virt-install', and it does seem to work fine. It would be a pity for > this to change). We definitely need to support 32-bit tools on 64-bit HV Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list