On Wed, May 24, 2017 at 12:49:58 +0200, Michal Privoznik wrote: > On 05/24/2017 12:32 PM, Martin Kletzander wrote: > > On Tue, May 23, 2017 at 05:29:52PM +0200, Peter Krempa wrote: > >> On Tue, May 23, 2017 at 17:19:53 +0200, Martin Kletzander wrote: > >>> On Tue, May 23, 2017 at 05:07:40PM +0200, Michal Privoznik wrote: [...] > >> Also compared to a full fragmentation of the returned data, this would > >> result into a worst-case-scenario memory usage of MAX_SIZE * > >> NVMS_QUERIED_IN_ORIGINAL_CALL, when compared to an unbounded memory use > >> of the full fragmentation approach. > > > > If I get what you are saying, then the same would happen if the mgmt app > > (or client) implemented it themselves. We would basically just provide > > the guessing logic. > > That's quite exact. I mean the word 'guessing'. We can't really provide > reliable way of dealing with what you're suggesting (unless we cut the > limit really small) nor we can guarantee atomicity. Therefore I think it > would be a waste of time to work on this. Yes, it can be done, but the > benefits are pretty small IMO. Yes, I agree. Therefore I opted to add the notice for this API.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
