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

[Bryan Drewery]

On 5/23/16 4:42 PM, Conrad Meyer wrote:
> On Mon, May 23, 2016 at 4:34 PM, Alan Somers  wrote:
>> On Mon, May 23, 2016 at 5:13 PM, Bryan Drewery  wrote:
>>>
>>> On 5/23/16 1:30 PM, Alan Somers wrote:
 UPDATING is updated as of r300539.  Any objection to merging this to
 stable/10?
>>>
>>> If any port uses it then yes.  Binaries are built from 10.1 and expected
>>> to work on 10.1, 10.2, 10.3, 10.4, etc.
>>
>>
>> Most ports that use bitstring should work.  The only ports that won't are
>> ports that either store bitstrings on disk or transmit them across a network
>> without an explicit serialization step.  A few other weird cases would break
>> too, like building a port on 10.3, updating sys/bitstring.h, then rebuilding
>> some object files but not others.  Is there any way to figure out what ports
>> might be using this header?  OpenHub code search didn't turn up anything.
> 
> It seems to me like this is exactly the sort of ABI breakage the
> stable/* branches promise not to make.

I just noticed that this is not a library. It's only macros. So I take
back what I said.


-- 
Regards,
Bryan Drewery
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Conrad Meyer]

On Mon, May 23, 2016 at 4:34 PM, Alan Somers  wrote:
> On Mon, May 23, 2016 at 5:13 PM, Bryan Drewery  wrote:
>>
>> On 5/23/16 1:30 PM, Alan Somers wrote:
>> > UPDATING is updated as of r300539.  Any objection to merging this to
>> > stable/10?
>>
>> If any port uses it then yes.  Binaries are built from 10.1 and expected
>> to work on 10.1, 10.2, 10.3, 10.4, etc.
>
>
> Most ports that use bitstring should work.  The only ports that won't are
> ports that either store bitstrings on disk or transmit them across a network
> without an explicit serialization step.  A few other weird cases would break
> too, like building a port on 10.3, updating sys/bitstring.h, then rebuilding
> some object files but not others.  Is there any way to figure out what ports
> might be using this header?  OpenHub code search didn't turn up anything.

It seems to me like this is exactly the sort of ABI breakage the
stable/* branches promise not to make.

On the other hand, it seems to me like the majority of the benefit of
this patch could be gained without breaking ABI.  (Optimistically
iterate longs rather than bytes if the pointer's alignment is
suitable.)

Best,
Conrad
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Alan Somers]

On Mon, May 23, 2016 at 5:13 PM, Bryan Drewery  wrote:

> On 5/23/16 1:30 PM, Alan Somers wrote:
> > UPDATING is updated as of r300539.  Any objection to merging this to
> > stable/10?
>
> If any port uses it then yes.  Binaries are built from 10.1 and expected
> to work on 10.1, 10.2, 10.3, 10.4, etc.
>
> --
> Regards,
> Bryan Drewery
>

Most ports that use bitstring should work.  The only ports that won't are
ports that either store bitstrings on disk or transmit them across a
network without an explicit serialization step.  A few other weird cases
would break too, like building a port on 10.3, updating sys/bitstring.h,
then rebuilding some object files but not others.  Is there any way to
figure out what ports might be using this header?  OpenHub code search
didn't turn up anything.

-Alan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Bryan Drewery]

On 5/23/16 1:30 PM, Alan Somers wrote:
> UPDATING is updated as of r300539.  Any objection to merging this to
> stable/10?

If any port uses it then yes.  Binaries are built from 10.1 and expected
to work on 10.1, 10.2, 10.3, 10.4, etc.

-- 
Regards,
Bryan Drewery
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Kurt Lidl]

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

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Peter Wemm]

On Thursday, May 05, 2016 10:57:16 AM Ed Maste wrote:
> On 4 May 2016 at 18:34, 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
> 
> tinderbox is failing on (at least) powerpc now with:
> 
> --- all_subdir_tests ---
> cc1: warnings being treated as errors
> /scratch/tmp/emaste/freebsd/sys/kern/subr_unit.c: In function 'main':
> /scratch/tmp/emaste/freebsd/sys/kern/subr_unit.c:1029: warning: format
> '%lu' expects type 'long unsigned int', but argument 2 has type
> 'unsigned int'
> *** [subr_unit.o] Error code 1
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

It also breaks i386:

In file included from /usr/src/usr.sbin/apmd/apmd.c:36:
In file included from /usr/obj/usr/src/tmp/usr/include/bitstring.h:34:
/usr/obj/usr/src/tmp/usr/include/sys/bitstring.h:278:13: error: implicit 
declaration of function '__bitcountl' is invalid in C99 [-Werror,-Wimplicit-
function-declaration]
_value += __bitcountl(*_curbitstr & mask);
  ^


-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.

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

[Alan Somers]

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?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Kurt Lidl]

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


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Bruce Evans]

On Thu, 5 May 2016, Alan Somers wrote:


On Thu, May 5, 2016 at 10:31 AM, John Baldwin  wrote:


On Wednesday, May 04, 2016 10:34:11 PM Alan Somers wrote:

...
Log:
  Improve performance and functionality of the bitstring(3) api

...
Doesn't switching from bytes to longs break the ABI?  That is, setting bit
9
...
Is the API is so little used we don't care?


The API isn't used in any shared libraries, so the only risk would be if
it's used in a user application where the user's build system doesn't check
for changes in system libraries, and the user upgrades FreeBSD without
doing a clean build of his application, right?  Am I missing any other
scenarios?  Do we need to warn users with a line in UPDATING or something?


All scenarios where the binary format is used for data layouts that live
for more than a few microseconds.  Little things like file systems and
networks.


This is similar to an upgrade of the C++ compiler.  C++ objects built by
different minor versions of the compiler aren't guaranteed to be compatible.


So C++ is also unsuitable for little things like file systems and networks
:-).

Bruce
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[John Baldwin]

On Thursday, May 05, 2016 10:45:21 AM Alan Somers wrote:
> On Thu, May 5, 2016 at 10:31 AM, 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?
> >
> > --
> > John Baldwin
> >
> 
> The API isn't used in any shared libraries, so the only risk would be if
> it's used in a user application where the user's build system doesn't check
> for changes in system libraries, and the user upgrades FreeBSD without
> doing a clean build of his application, right?  Am I missing any other
> scenarios?  Do we need to warn users with a line in UPDATING or something?

It would matter more if it was used in any 3rd party applications (e.g. in
/usr/ports), though it needs to cross an API boundary to matter.  I can believe
that bitstring(3) is obscure enough that nothing uses it, but the ABI needs to
be considered.  We can't ever change cpuset_t from longs to uint32_t's for
example (which is what sigset_t uses) because it is used in various system
calls (e.g. consider using cpuset(8) in an old jail).

> This is similar to an upgrade of the C++ compiler.  C++ objects built by
> different minor versions of the compiler aren't guaranteed to be compatible.

Erm, that's definitely not true.  Changes to libstdc++ or libc++ might
generate incompatible objects, and there has been a lot of anguish in the past
when GCC has done that (see how it had to revert changes to std::list in
libstdc++ that were done to make it C++11 compliant but broke the ABI of
std::list).  You can even mix objects from GCC and clang and it will work fine
(e.g. use clang or newer versions of GCC to build user applications that link
against libraries in the base system built with a different version of either
gcc or clang).

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Zbigniew Bodek]

Hi,

It broke build for ARM64 but fixed here:
https://svnweb.freebsd.org/changeset/base/299124

Best regards
zbb

2016-05-05 18:45 GMT+02:00 Alan Somers :

> On Thu, May 5, 2016 at 10:31 AM, 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?
> >
> > --
> > John Baldwin
> >
>
> The API isn't used in any shared libraries, so the only risk would be if
> it's used in a user application where the user's build system doesn't check
> for changes in system libraries, and the user upgrades FreeBSD without
> doing a clean build of his application, right?  Am I missing any other
> scenarios?  Do we need to warn users with a line in UPDATING or something?
>
> This is similar to an upgrade of the C++ compiler.  C++ objects built by
> different minor versions of the compiler aren't guaranteed to be
> compatible.
>
> -Alan
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Alan Somers]

On Thu, May 5, 2016 at 10:31 AM, 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?
>
> --
> John Baldwin
>

The API isn't used in any shared libraries, so the only risk would be if
it's used in a user application where the user's build system doesn't check
for changes in system libraries, and the user upgrades FreeBSD without
doing a clean build of his application, right?  Am I missing any other
scenarios?  Do we need to warn users with a line in UPDATING or something?

This is similar to an upgrade of the C++ compiler.  C++ objects built by
different minor versions of the compiler aren't guaranteed to be compatible.

-Alan
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[John Baldwin]

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?

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Ed Maste]

On 4 May 2016 at 18:34, 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

tinderbox is failing on (at least) powerpc now with:

--- all_subdir_tests ---
cc1: warnings being treated as errors
/scratch/tmp/emaste/freebsd/sys/kern/subr_unit.c: In function 'main':
/scratch/tmp/emaste/freebsd/sys/kern/subr_unit.c:1029: warning: format
'%lu' expects type 'long unsigned int', but argument 2 has type
'unsigned int'
*** [subr_unit.o] Error code 1
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Alan Somers]

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.
  
  sys/sys/bitstring.h:
  Convert the majority of the existing bit string implementation from
  macros to inline functions.
  
  Properly protect the implementation from inadvertant macro expansion
  when included in a user's program by prefixing all private
  macros/functions and local variables with '_'.
  
  Add bit_ffs_at() and bit_ffc_at(). Implement bit_ffs() and
  bit_ffc() in terms of their "at" counterparts.
  
  Provide a kernel implementation of bit_alloc(), making the full API
  usable in the kernel.
  
  Improve code documenation.
  
  share/man/man3/bitstring.3:
  Add pre-exisiting API bit_ffc() to the synopsis.
  
  Document new APIs.
  
  Document the initialization state of the bit strings
  allocated/declared by bit_alloc() and bit_decl().
  
  Correct documentation for bitstr_size(). The original code comments
  indicate the size is in bytes, not "elements of bitstr_t". The new
  implementation follows this lead. Only hastd assumed "elements"
  rather than bytes and it has been corrected.
  
  etc/mtree/BSD.tests.dist:
  tests/sys/Makefile:
  tests/sys/sys/Makefile:
  tests/sys/sys/bitstring.c:
  Add tests for all existing and new functionality.
  
  include/bitstring.h
Include all headers needed by sys/bitstring.h
  
  lib/libbluetooth/bluetooth.h:
  usr.sbin/bluetooth/hccontrol/le.c:
  Include bitstring.h instead of sys/bitstring.h.
  
  sbin/hastd/activemap.c:
  Correct usage of bitstr_size().
  
  sys/dev/xen/blkback/blkback.c
  Use new bit_alloc.
  
  sys/kern/subr_unit.c:
  Remove hard-coded assumption that sizeof(bitstr_t) is 1.  Get rid of
  unrb.busy, which caches the number of bits set in unrb.map.  When
  INVARIANTS are disabled, nothing needs to know that information.
  callapse_unr can be adapted to use bit_ffs and bit_ffc instead.
  Eliminating unrb.busy saves memory, simplifies the code, and
  provides a slight speedup when INVARIANTS are disabled.
  
  sys/net/flowtable.c:
  Use the new kernel implementation of bit-alloc, instead of hacking
  the old libc-dependent macro.
  
  sys/sys/param.h
  Update __FreeBSD_version to indicate availability of new API
  
  Submitted by:   gibbs, asomers
  Reviewed by:gibbs, ngie
  MFC after:  4 weeks
  Sponsored by:   Spectra Logic Corp
  Differential Revision:  https://reviews.freebsd.org/D6004

Added:
  head/tests/sys/sys/
  head/tests/sys/sys/Makefile   (contents, props changed)
  head/tests/sys/sys/bitstring_test.c   (contents, props changed)
Modified:
  head/etc/mtree/BSD.tests.dist
  head/include/bitstring.h
  head/lib/libbluetooth/bluetooth.h
  head/sbin/hastd/activemap.c
  head/share/man/man3/bitstring.3
  head/sys/dev/xen/blkback/blkback.c
  head/sys/kern/subr_unit.c
  head/sys/net/flowtable.c
  head/sys/sys/bitstring.h
  head/sys/sys/param.h
  head/tests/sys/Makefile
  head/usr.sbin/bluetooth/hccontrol/le.c

Modified: head/etc/mtree/BSD.tests.dist
==
--- head/etc/mtree/BSD.tests.dist   Wed May  4 22:27:22 2016
(r299089)
+++ head/etc/mtree/BSD.tests.dist   Wed May  4 22:34:11 2016
(r299090)
@@ -460,6 +460,8 @@
 ..
 posixshm
 ..
+sys
+..
 vfs
 ..
 vm

Modified: head/include/bitstring.h
==
--- head/include/bitstring.hWed May  4 22:27:22 2016(r299089)
+++ head/include/bitstring.hWed May  4 22:34:11 2016(r299090)
@@ -29,6 +29,8 @@
 #ifndef _BITSTRING_H_
 #define_BITSTRING_H_
 
+#include 
+#include 
 #include 
 
 #endif /* _BITSTRING_H_ */

Modified: head/lib/libbluetooth/bluetooth.h
==
--- head/lib/libbluetooth/bluetooth.h   Wed May  4 22:27:22 2016