From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHgWC-0007uk-5y for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:33:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHgW6-0007sU-3I for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:32:58 -0500 Received: from [199.232.76.173] (port=46841 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHgW5-0007sL-6V for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:32:53 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]:29814) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHgW5-0008AZ-FV for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:32:53 -0500 Received: by fg-out-1718.google.com with SMTP id e12so694007fga.10 for ; Mon, 07 Dec 2009 08:32:51 -0800 (PST) Message-ID: <4B1D2E2E.6060907@codemonkey.ws> Date: Mon, 07 Dec 2009 10:32:46 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B1D2462.3070000@codemonkey.ws> <4B1D2696.5080003@redhat.com> <4B1D27EE.7060400@codemonkey.ws> <4B1D292D.4010700@redhat.com> <4B1D2B54.40402@codemonkey.ws> <4B1D2CC2.7010806@redhat.com> In-Reply-To: <4B1D2CC2.7010806@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Paul Brook , Markus Armbruster , qemu-devel@nongnu.org Avi Kivity wrote: > On 12/07/2009 06:20 PM, Anthony Liguori wrote: >> Avi Kivity wrote: >>>> Covering every qemu_malloc instance this close to the GA is too >>>> risky. I agree that having separate behavior is less than ideal >>>> but I think it's the only sane way forward. >>>> >>> >>> I don't understand why. What's so insane about Markus' patch? >>> Allowing size=0 for both developer and production builds? >> >> There is a bug here. Callers are calling qemu_malloc incorrectly. >> >> There is an open discussion about how to address it--fix all callers >> of qemu_malloc() or allow size=0. Since there isn't agreement, a >> compromise of sticking to the current behavior for the development >> tree, and using the later for production since we can't guarantee the >> former seems reasonable. > > If we apply the patch, the callers are no longer incorrect. Since > we're winding down development on that tree, I see no reason for the > production build to be correct and the development tree to be incorrect. The problem with this whole discussion is taking the position that one form is "correct" while the other form is "incorrect". It's not so black and white. I don't think a reasonable person can claim that either form of qemu_malloc() is absolutely correct while the other is incorrect. You may think one is better than the other but clearly, that sentiment is not universally shared. If we change the production build, we eliminate the immediate problem. For 0.13, we can reduce the usage of qemu_malloc() such that it stops becoming an issue. Then no one ever has to agree about which form is better and we can move on with our lives. Regards, Anthony Liguori