On Wed, Mar 21, 2007 at 01:55:35PM +0000, Mark McLoughlin wrote: > - I think the use case is a little different - generally in libvirt, > we're only allocating very small chunks where the CPU hit for > initialisation would be negligible and would never show up on a > profile. I'd prefer to take the minor hit of zero-initialising > most/all memory for programming ease. > > - If our wrappers always zero-initialise, we don't need the > "initialise to -1 when debugging" thing. > > - If we rely on calloc() zero-initialising in our wrappers, we give > opportunity for libc to optimise where it knows the memory is > already initialised - e.g. where it's mmap()ing the memory > from /dev/zero okay, okay, let's use calloc() for libvirt, but then there is a number of places where I probably used memset() for zeroing, they should all be cleaned up. > Ah, memory usage reports ... nice. Would such a report be less useful > with the two mixed together, though? e.g. I personally would just like > to see the libvirt memory usage, rather than libxml2, in such a report. well memory allocated by libxml2 as strings my be kept for libvirt own usage > Again, though, I think libvirt has slightly different needs from a > malloc() wrapper. yes, agreed. > > okay, I assume those reporting layers are missing ATM, right ? > > Nope, it's all there. > > See, in qemudAddIptablesRules() we set VIR_ERR_NO_MEMORY if > iptablesContextNew() returns NULL, qemudAutostartConfigs() calls > qemudLog() if an error is set and qemudLog(), in turn, reports to > syslog. then all calloc/malloc calls in qemud should get that report code (maybe factored to avoid repeated code ?) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/