From owner-svn-src-all@freebsd.org Mon May 23 22:59:08 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D368AB4715F; Mon, 23 May 2016 22:59:08 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ADDD11D32; Mon, 23 May 2016 22:59:08 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net (torb.pix.net [192.168.16.32]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u4NMx7KZ030783; Mon, 23 May 2016 18:59:07 -0400 (EDT) (envelope-from lidl@pix.net) Subject: Re: svn commit: r299090 - in head: etc/mtree include lib/libbluetooth sbin/hastd share/man/man3 sys/dev/xen/blkback sys/kern sys/net sys/sys tests/sys tests/sys/sys usr.sbin/bluetooth/hccontrol To: Alan Somers References: <201605042234.u44MYBMX054443@repo.freebsd.org> <2368543.Vvp613SNcD@ralph.baldwin.cx> <684f4a82-f48c-b2bb-6a72-5c1dfea11a39@pix.net> Cc: John Baldwin , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Kurt Lidl Message-ID: Date: Mon, 23 May 2016 18:59:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 22:59:08 -0000 On 5/23/16 4:30 PM, Alan Somers wrote: > On Fri, May 6, 2016 at 8:45 AM, Kurt Lidl > wrote: > > On 5/5/16 12:31 PM, John Baldwin wrote: > > On Wednesday, May 04, 2016 10:34:11 PM Alan Somers wrote: > > Author: asomers > Date: Wed May 4 22:34:11 2016 > New Revision: 299090 > URL: https://svnweb.freebsd.org/changeset/base/299090 > > Log: > Improve performance and functionality of the bitstring(3) api > > Two new functions are provided, bit_ffs_at() and > bit_ffc_at(), which allow > for efficient searching of set or cleared bits starting > from any bit offset > within the bit string. > > Performance is improved by operating on longs instead of > bytes and using > ffsl() for searches within a long. ffsl() is a compiler > builtin in both > clang and gcc for most architectures, converting what was > a brute force > while loop search into a couple of instructions. > > All of the bitstring(3) API continues to be contained in > the header file. > Some of the functions are large enough that perhaps they > should be uninlined > and moved to a library, but that is beyond the scope of > this commit. > > > Doesn't switching from bytes to longs break the ABI? That is, > setting bit 9 > now has a different representation on big-endian systems (0x00 > 0x01 before, > now 0x00 0x00 0x01 0x00 on 32-bit BE, and 4 more leading 0 bytes > on 64-bit). > This means you can't have an object file compiled against the > old header > pass a bitstring to an object file compiled against the new > header on big-endian > systems. > > Even on little-endian systems if an old object file allocates > storage for a > bitstring the new code might read off the end of it and fault > (or return > garbage if bits are set in the extra bytes it reads off the end)? > > Is the API is so little used we don't care? > > > Just as a note - at my prior job (Pi-Coral, now defunct) we used this > API everywhere in the dataplane code of our product. Since the company > is gone, that particular use-case doesn't matter anymore. > > At the very least, this deserves a mention in the release notes, and > also UPDATING! > > -Kurt > > > UPDATING is updated as of r300539. Any objection to merging this to > stable/10? Not to me - as I mentioned, the company went out of business, so catering to its needs is a NOP. Go for it! -Kurt