From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpPqz-0004FO-7v for qemu-devel@nongnu.org; Thu, 12 Jul 2012 16:19:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpPqx-00060v-8R for qemu-devel@nongnu.org; Thu, 12 Jul 2012 16:19:13 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:57440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpPqx-00060p-4a for qemu-devel@nongnu.org; Thu, 12 Jul 2012 16:19:11 -0400 Received: by yhpp34 with SMTP id p34so1054336yhp.4 for ; Thu, 12 Jul 2012 13:19:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Thu, 12 Jul 2012 20:18:50 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v2 1/3] bitops: fix types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Markus Armbruster , qemu-devel On Tue, Jul 10, 2012 at 9:36 PM, Peter Maydell wrote: > On 10 July 2012 21:01, Blue Swirl wrote: >> On Tue, Jul 10, 2012 at 7:37 PM, Peter Maydell wrote: >>> On 10 July 2012 20:18, Blue Swirl wrote: >>>> On Mon, Jul 9, 2012 at 7:49 AM, Markus Armbruster wrote: >>>>> There is no consensus. I recognize the power of maintainers to force a >>>>> change even without consensus. Use it wisely. >>>> >>>> I thought I refuted all concrete arguments except performance. >>> >>> No, you made various claims that Markus and I at least >>> disagreed with. (Conversely, we have made various claims >>> that you disagree with -- this is what "no consensus" means...) >> >> You did not present any concrete arguments. In this review you have >> pointed at bugs in the assert() expression, thanks. > > No, a bug in your assert is an indication of why there are > downsides to making random changes, not a concrete argument > against making the changes. The major problem here > is (a) there is no really good reason to make this change There are inconsistencies in the API that need fixing (unsigned long vs. int) and a technically improved solution (unsigned int in x86_64) exists. These are good and valid reasons. > (b) it's moving away from the existing tested code we have > (and that the kernel has). Keeping the code intact should not stop progress: fix inconsistencies and use a better solution. The distance from kernel is questionable value BTW: have you checked how little bitops.h resembles the kernel versions? > Basically 'int' has more natural > behaviour for reasoning about than 'unsigned' in ranges > where it's usually used (ie small ones). But 'unsigned' is much more naturally suited to values that can't be negative. This part is bikeshedding, your point of view against mine. Currently some functions use 'unsigned long' for bit numbers, shouldn't they be changed to 'int' in your logic? > > -- PMM