Revision tags: release/14.0.0 |
|
#
b3e76948 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
d915a14e |
| 25-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
libc: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using mis-identified many licenses so this was mostly a manual - error p
libc: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using mis-identified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0 |
|
#
a4bf5fb9 |
| 28-Apr-2010 |
Kirk McKusick <mckusick@FreeBSD.org> |
Update to current version of head.
|
#
f5ccef8f |
| 22-Mar-2010 |
John Baldwin <jhb@FreeBSD.org> |
MFC 204950,205020: Use thr_once() with once_t controls to initialize various thread_key_t objects used to provide per-thread storage in the RPC code. Almost all of these used double-checking with a
MFC 204950,205020: Use thr_once() with once_t controls to initialize various thread_key_t objects used to provide per-thread storage in the RPC code. Almost all of these used double-checking with a dedicated mutex (tsd_lock) to do this before. However, that is not always safe with more relaxed memory orders. There were also other bugs, such as one in __rpc_createrr() that caused a new key to be allocated each time __rpc_createrr() was invoked.
show more ...
|
Revision tags: release/7.3.0_cvs, release/7.3.0 |
|
#
6f88d2a8 |
| 10-Mar-2010 |
John Baldwin <jhb@FreeBSD.org> |
Use thr_once() with once_t controls to initialize various thread_key_t objects used to provide per-thread storage in the RPC code. Almost all of these used double-checking with a dedicated mutex (ts
Use thr_once() with once_t controls to initialize various thread_key_t objects used to provide per-thread storage in the RPC code. Almost all of these used double-checking with a dedicated mutex (tsd_lock) to do this before. However, that is not always safe with more relaxed memory orders. There were also other bugs, such as one in __rpc_createrr() that caused a new key to be allocated each time __rpc_createrr() was invoked.
PR: threads/144558 Reported by: Sam Robb samrobb of averesystems com (key leak) MFC after: 1 week
show more ...
|
Revision tags: release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0 |
|
#
30b86e87 |
| 28-Feb-2006 |
Xin LI <delphij@FreeBSD.org> |
Don't do a time travel to 12006...
|
#
235baf26 |
| 27-Feb-2006 |
Daniel Eischen <deischen@FreeBSD.org> |
Staticize a couple of functions.
Remove a few unused locks.
Remove locks from application namespace.
|
Revision tags: release/7.3.0_cvs, release/7.3.0 |
|
#
6f88d2a8 |
| 10-Mar-2010 |
John Baldwin <jhb@FreeBSD.org> |
Use thr_once() with once_t controls to initialize various thread_key_t objects used to provide per-thread storage in the RPC code. Almost all of these used double-checking with a dedicated mutex (ts
Use thr_once() with once_t controls to initialize various thread_key_t objects used to provide per-thread storage in the RPC code. Almost all of these used double-checking with a dedicated mutex (tsd_lock) to do this before. However, that is not always safe with more relaxed memory orders. There were also other bugs, such as one in __rpc_createrr() that caused a new key to be allocated each time __rpc_createrr() was invoked.
PR: threads/144558 Reported by: Sam Robb samrobb of averesystems com (key leak) MFC after: 1 week
show more ...
|
Revision tags: release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0 |
|
#
30b86e87 |
| 28-Feb-2006 |
Xin LI <delphij@FreeBSD.org> |
Don't do a time travel to 12006...
|
#
235baf26 |
| 27-Feb-2006 |
Daniel Eischen <deischen@FreeBSD.org> |
Staticize a couple of functions.
Remove a few unused locks.
Remove locks from application namespace.
|