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

[Kurt Lidl]

On 5/23/16 4:30 PM, Alan Somers wrote:
> On Fri, May 6, 2016 at 8:45 AM, Kurt Lidl <lidl at pix.net
> <mailto:lidl at pix.net>> 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