Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265792AbUARFxg (ORCPT ); Sun, 18 Jan 2004 00:53:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266219AbUARFxf (ORCPT ); Sun, 18 Jan 2004 00:53:35 -0500 Received: from holomorphy.com ([199.26.172.102]:14764 "EHLO holomorphy.com") by vger.kernel.org with ESMTP id S265792AbUARFxe (ORCPT ); Sun, 18 Jan 2004 00:53:34 -0500 Date: Sat, 17 Jan 2004 21:52:33 -0800 From: William Lee Irwin III To: Paul Jackson Cc: joe.korty@ccur.com, linux-kernel@vger.kernel.org, colpatch@us.ibm.com, akpm@osdl.org, paulus@samba.org Subject: Re: [PATCH] bitmap parsing routines, version 3 Message-ID: <20040118055233.GA24421@holomorphy.com> Mail-Followup-To: William Lee Irwin III , Paul Jackson , joe.korty@ccur.com, linux-kernel@vger.kernel.org, colpatch@us.ibm.com, akpm@osdl.org, paulus@samba.org References: <20040114204009.3dc4c225.pj@sgi.com> <20040115081533.63c61d7f.akpm@osdl.org> <20040115181525.GA31086@tsunami.ccur.com> <20040115161732.458159f5.pj@sgi.com> <400873EC.2000406@us.ibm.com> <20040117063618.GA14829@tsunami.ccur.com> <20040117020815.3ac17c46.pj@sgi.com> <20040117145545.GA16318@tsunami.ccur.com> <20040117153615.GA16385@tsunami.ccur.com> <20040117153344.1072ae7c.pj@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040117153344.1072ae7c.pj@sgi.com> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1313 Lines: 26 On Sat, Jan 17, 2004 at 03:33:44PM -0800, Paul Jackson wrote: > Having the various bitop routines cease treating the unused high bits as > a garbage dump is a separate task. I don't like the way it is, as it > seems to open the door for some random bugs, in case some hapless code > is depending on these high bits in ways it shouldn't. > This whole mechanism seems to have a design confusion - whether to > specify and honor a specific bit count, or not. There has never been any confusion. The slop bits are treated consistently as "don't cares". The functions used to inspect the values, bitmap_empty(), bitmap_full(), bitmap_equal(), and bitmap_weight(), all properly check the boundary cases. The remaining functions clobber the slop bits without hesitation in order to simplify the implementation, as those bits are never examined by the inspection functions. If those bits are ever examined and interpreted when they should not be, I'd be far more interested in hearing about that than about don't cares being clobbered when they are supposed to be. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/