From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebq45-00051h-Ab for qemu-devel@nongnu.org; Wed, 17 Jan 2018 10:55:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebq41-0001Gv-Eb for qemu-devel@nongnu.org; Wed, 17 Jan 2018 10:55:49 -0500 From: Alberto Garcia In-Reply-To: References: <192986ad741749064e855bc67916a11460911992.1513342045.git.berto@igalia.com> Date: Wed, 17 Jan 2018 16:55:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v2 16/32] qcow2: Update l2_allocate() to support L2 slices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , "Denis V . Lunev" , qemu-block@nongnu.org, Max Reitz On Tue 16 Jan 2018 11:26:40 PM CET, Eric Blake wrote: >> /* allocate a new entry in the l2 cache */ >> >> + slice_size = s->l2_slice_size * sizeof(uint64_t); > > Would this read any better if the earlier patch named it > s->l2_slice_entries? I had doubts with this. Like you, when I see size I tend to think about bytes. However both s->l1_size and s->l2_size indicate entries, and the documentation of the qcow2 format even describes the header field like this: 36 - 39: l1_size Number of entries in the active L1 table So I decided to follow that same convention for l2_slice_size. For the local variable I could call it slice_size_bytes or try to come up with a different alternative, but I'm open to suggestions. Berto