Date: Fri, 6 May 2016 10:45:24 -0400 From: Kurt Lidl <lidl@pix.net> To: John Baldwin <jhb@freebsd.org>, Alan Somers <asomers@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org 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 Message-ID: <684f4a82-f48c-b2bb-6a72-5c1dfea11a39@pix.net> In-Reply-To: <2368543.Vvp613SNcD@ralph.baldwin.cx> References: <201605042234.u44MYBMX054443@repo.freebsd.org> <2368543.Vvp613SNcD@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?684f4a82-f48c-b2bb-6a72-5c1dfea11a39>