From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUod5-000695-TZ for qemu-devel@nongnu.org; Wed, 04 Feb 2009 15:45:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUod5-00068j-Bq for qemu-devel@nongnu.org; Wed, 04 Feb 2009 15:45:51 -0500 Received: from [199.232.76.173] (port=57658 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUod5-00068f-4N for qemu-devel@nongnu.org; Wed, 04 Feb 2009 15:45:51 -0500 Received: from mx2.redhat.com ([66.187.237.31]:35799) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUod4-0006wz-KP for qemu-devel@nongnu.org; Wed, 04 Feb 2009 15:45:50 -0500 Message-ID: <4989FE92.5020400@redhat.com> Date: Wed, 04 Feb 2009 22:46:10 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1233750314-23301-1-git-send-email-avi@redhat.com> <1233750314-23301-2-git-send-email-avi@redhat.com> <4989EC29.9050705@us.ibm.com> <4989FACD.6090309@redhat.com> <4989FC3B.7010407@us.ibm.com> In-Reply-To: <4989FC3B.7010407@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/4] Add a scatter-gather list type and accessors Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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. 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. >> 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. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.