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

[Anthony Liguori]

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