From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751502AbdLSRfu (ORCPT ); Tue, 19 Dec 2017 12:35:50 -0500 Received: from mga09.intel.com ([134.134.136.24]:18047 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750866AbdLSRfj (ORCPT ); Tue, 19 Dec 2017 12:35:39 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,427,1508828400"; d="scan'208";a="3120606" Message-ID: <1513704756.7000.209.camel@linux.intel.com> Subject: Re: bitmap API consistency From: Andy Shevchenko To: Rasmus Villemoes Cc: Andrew Morton , LKML , Martin Schwidefsky Date: Tue, 19 Dec 2017 19:32:36 +0200 In-Reply-To: <1495629805.6967.101.camel@linux.intel.com> References: <1495627881.6967.99.camel@linux.intel.com> <1495629805.6967.101.camel@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-05-24 at 15:43 +0300, Andy Shevchenko wrote: > On Wed, 2017-05-24 at 14:38 +0200, Rasmus Villemoes wrote: > > On 24 May 2017 at 14:11, Andy Shevchenko > > wrote: > > > Hi! > > > > > > Surprisingly discovered today that bitmap API is not consistent in > > > some > > > cases (at least one I found recently). > > > > > > bitmap_fill() sets area of bits in a bitmap. > > > bitmap_zero() clears them. > > > > > > However, if _fill() does something sane, _zero() clears _all_ bits > > > up to > > > word size (long). > > > > > > I think it should be fixed to be consistent with _fill() variant. > > > > What do you want it to do? > > Based on my vision and your answer below, thanks for it, I think we > need > to > a) make _fill() to fill entire _aligned_ area > b) update comments in the header and documentation, if needed, to > specify that _fill() / _zero() operates on aligned to word size area, > while _set() and _clear() do exact amount of bits. 7 months passed, can we eventually do something about it? > > It always acts on whole words, so the last > > word must be set to something. One might as well say that _zero and > > _fill are consistent in that they both set the bits beyond nbits in > > the last word to 0. > > > > If anything, I'd change bitmap_fill to do a memset(0xff) of the > > entire > > region. There used to be bugs where some of the bitmap_* functions > > didn't actually ignore the trailing bits, making it somewhat > > important > > that they were always 0, but I think they're fixed now. > > > > Note that if one wants a guarantee that the trailing bits are not > > touched at all, the APIs to use are bitmap_{set, clear}(dst, 0, > > count). bitmap_{zero,fill} assumes that nbits is the total size of > > the > > bitmap (i.e. that the user will never care about bits beyond nbits). > > Maybe a few comments could be added somewhere. -- Andy Shevchenko Intel Finland Oy