From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH] Replacing (and removing) get_ticks_per_sec() function with NANOSECONDS_PER_SECOND Signed-off-by: Rutuja Shah Date: Fri, 11 Mar 2016 12:44:33 +0100 Message-ID: <56E2AFA1.5010201@de.ibm.com> References: <1457638209-14218-1-git-send-email-rutu.shah.26@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: peter.maydell@linaro.org, kvm@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, mark.cave-ayland@ilande.co.uk, lcapitulino@redhat.com, kraxel@redhat.com, qemu-block@nongnu.org, agraf@suse.de, samuel.thibault@ens-lyon.org, balrogg@gmail.com, alistair.francis@xilinx.com, qemu-arm@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, cornelia.huck@de.ibm.com, rth@twiddle.net, kwolf@redhat.com, crosthwaite.peter@gmail.com, armbru@redhat.com, blauwirbel@gmail.co, qemu-ppc@nongnu.org, imammedo@redhat.com To: rutu.shah.26@gmail.com, qemu-devel@nongnu.org Return-path: In-Reply-To: <1457638209-14218-1-git-send-email-rutu.shah.26@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-block-bounces+gceqb-qemu-block=m.gmane.org@nongnu.org Sender: qemu-block-bounces+gceqb-qemu-block=m.gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 03/10/2016 08:30 PM, rutu.shah.26@gmail.com wrote: > From: Rutuja Shah [...] > - s->tick_offset_vmstate = s->tick_offset + delta / get_ticks_per_sec(); > + s->tick_offset_vmstate = s->tick_offset + delta / NANOSECONDS_PER_SECOND; [...] While technically correct, I do not like these changes. The interfaces expect "ticks", and the fact that this happens to be a nanosecond does not help regarding readability. Lets look at the snippet from above. The variable is called TICK_offset_vmstate. so, the first line (-) makes sense when reading, the 2nd line (+) does not. A reader that does not know the timer code will ask itself: "Why do we use NANOSECONDS_PER_SECOND to calculate ticks?" The reader has to know that a tick is a nanosecond to understand that line. So the cleanup makes the code harder to read in my opinion. If - for some reason - we want to replace a function with a MACRO, then please introduce TICKS_PER_SECOND which just feels better when reading the code. It would also fix the >80 chars per line problem. On the other hand get_ticks_per_sec is a static inline function: - it will get inlined, no overhead over a macro - it will add type safety if we ever change things (e.g. somebody might introduce a tick_t) So I would prefer to not change things. Christian From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeLUs-0007bo-KN for qemu-devel@nongnu.org; Fri, 11 Mar 2016 06:44:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeLUq-000893-Dq for qemu-devel@nongnu.org; Fri, 11 Mar 2016 06:44:46 -0500 Received: from e06smtp09.uk.ibm.com ([195.75.94.105]:49823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeLUq-00087z-5b for qemu-devel@nongnu.org; Fri, 11 Mar 2016 06:44:44 -0500 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 11 Mar 2016 11:44:39 -0000 References: <1457638209-14218-1-git-send-email-rutu.shah.26@gmail.com> From: Christian Borntraeger Message-ID: <56E2AFA1.5010201@de.ibm.com> Date: Fri, 11 Mar 2016 12:44:33 +0100 MIME-Version: 1.0 In-Reply-To: <1457638209-14218-1-git-send-email-rutu.shah.26@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Replacing (and removing) get_ticks_per_sec() function with NANOSECONDS_PER_SECOND Signed-off-by: Rutuja Shah List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rutu.shah.26@gmail.com, qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, kvm@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, mark.cave-ayland@ilande.co.uk, lcapitulino@redhat.com, kraxel@redhat.com, qemu-block@nongnu.org, agraf@suse.de, samuel.thibault@ens-lyon.org, alistair.francis@xilinx.com, qemu-arm@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, cornelia.huck@de.ibm.com, jsnow@redhat.com, rth@twiddle.net, kwolf@redhat.com, crosthwaite.peter@gmail.com, armbru@redhat.com, blauwirbel@gmail.co, qemu-ppc@nongnu.org, imammedo@redhat.com On 03/10/2016 08:30 PM, rutu.shah.26@gmail.com wrote: > From: Rutuja Shah [...] > - s->tick_offset_vmstate = s->tick_offset + delta / get_ticks_per_sec(); > + s->tick_offset_vmstate = s->tick_offset + delta / NANOSECONDS_PER_SECOND; [...] While technically correct, I do not like these changes. The interfaces expect "ticks", and the fact that this happens to be a nanosecond does not help regarding readability. Lets look at the snippet from above. The variable is called TICK_offset_vmstate. so, the first line (-) makes sense when reading, the 2nd line (+) does not. A reader that does not know the timer code will ask itself: "Why do we use NANOSECONDS_PER_SECOND to calculate ticks?" The reader has to know that a tick is a nanosecond to understand that line. So the cleanup makes the code harder to read in my opinion. If - for some reason - we want to replace a function with a MACRO, then please introduce TICKS_PER_SECOND which just feels better when reading the code. It would also fix the >80 chars per line problem. On the other hand get_ticks_per_sec is a static inline function: - it will get inlined, no overhead over a macro - it will add type safety if we ever change things (e.g. somebody might introduce a tick_t) So I would prefer to not change things. Christian