[Qemu-devel] Re: [PATCH 1/4] Add a scatter-gather list type and accessors

[Anthony Liguori <aliguori@us.ibm.com>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> Is it possible to have a blanket license for files which don't have 
>>> explicit terms?  I don't much like boilerplate.
>>
>> I'd greatly prefer not to.  You can refer to a COPYING and we can 
>> have a default COPYING file but a copyright is really needed as far 
>> as I understand it.
>>
>
> Okay.  I'll add an explicit license and leave the generic license to 
> our esteemed maintainers.
>
>>>> Would be nice to check for malloc failures and fail gracefully at 
>>>> least.
>>>
>>> Do you mean an exit(1)?  If so we could just put it in qemu_malloc().
>>
>> In theory, some users may be able to cope with malloc failure.  In 
>> practice, I don't think anyone can.  I'm open to suggestion.
>
> malloc() will never fail on Linux with overcommit enabled; since Linux 
> is fairly useless without overcommit, it means you'll never see a 
> failure.

Sure it will.  You just have to run out of VA space.

> Other ways of allocating memory (stack growth, first access to 
> anonymous memory) are not covered.  They can fail (most ungracefully) 
> without strict overcommit control.
>
> So I suggest to have qemu_malloc() and its friends abort on failure.

As I said, I'm not at all opposed to this.  glib does this and it makes 
life a lot easier.

>>> I expect this to trigger rarely since the allocation hint should 
>>> suffice nearly 100% of the time.  But in case we miss, it's better 
>>> to reallocate as little as possible.
>>>
>>> (what I really want is std::vector<>)
>>
>> Which I'm pretty sure has a linear growth strategy :-)
>
> Not in any of the implementations I'm familiar with.  I believe 
> std::vector<> is required to have amortized O(1) append operations.

Linear growth doesn't imply element-by-element growth.  You can have a 
coefficient > 1.

Regards,

Anthony Liguori