Revision tags: release/14.0.0 |
|
#
71625ec9 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c comment pattern
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
d3d79e96 |
| 03-Nov-2020 |
John Baldwin <jhb@FreeBSD.org> |
Consistently use C99 fixed-width types in the in-kernel crypto code.
Reviewed by: markj Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D27061
|
Revision tags: release/12.2.0, release/11.4.0, release/12.1.0 |
|
#
0ed1d6fb |
| 01-Aug-2019 |
Xin LI <delphij@FreeBSD.org> |
Allow Kernel to link in both legacy libkern/zlib and new sys/contrib/zlib, with an eventual goal to convert all legacl zlib callers to the new zlib version:
* Move generic zlib shims that are not s
Allow Kernel to link in both legacy libkern/zlib and new sys/contrib/zlib, with an eventual goal to convert all legacl zlib callers to the new zlib version:
* Move generic zlib shims that are not specific to zlib 1.0.4 to sys/dev/zlib. * Connect new zlib (1.2.11) to the zlib kernel module, currently built with Z_SOLO. * Prefix the legacy zlib (1.0.4) with 'zlib104_' namespace. * Convert sys/opencrypto/cryptodeflate.c to use new zlib. * Remove bundled zlib 1.2.3 from ZFS and adapt it to new zlib and make it depend on the zlib module. * Fix Z_SOLO build of new zlib.
PR: 229763 Submitted by: Yoshihiro Ota <ota j email ne jp> Reviewed by: markm (sys/dev/zlib/zlib_kmod.c) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D19706
show more ...
|
Revision tags: release/11.3.0, release/12.0.0, release/11.2.0, release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0 |
|
#
416ba5c7 |
| 22-Jun-2015 |
Navdeep Parhar <np@FreeBSD.org> |
Catch up with HEAD (r280229-r284686).
|
#
98e0ffae |
| 27-May-2015 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge sync of head
|
#
7757a1b4 |
| 03-May-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from head
|
#
de7df74b |
| 01-May-2015 |
Glen Barber <gjb@FreeBSD.org> |
MFH: r281855-r282312
Sponsored by: The FreeBSD Foundation
|
#
d9db5225 |
| 22-Apr-2015 |
Craig Rodrigues <rodrigc@FreeBSD.org> |
Move zlib.c from net to libkern.
It is not network-specific code and would be better as part of libkern instead. Move zlib.h and zutil.h from net/ to sys/ Update includes to use sys/zlib.h and sys/z
Move zlib.c from net to libkern.
It is not network-specific code and would be better as part of libkern instead. Move zlib.h and zutil.h from net/ to sys/ Update includes to use sys/zlib.h and sys/zutil.h instead of net/
Submitted by: Steve Kiernan stevek@juniper.net Obtained from: Juniper Networks, Inc. GitHub Pull Request: https://github.com/freebsd/freebsd/pull/28 Relnotes: yes
show more ...
|
Revision tags: 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, release/7.3.0_cvs, release/7.3.0 |
|
#
1a0fda2b |
| 04-Mar-2010 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
IFH@204581
|
#
9199c09a |
| 06-Jan-2010 |
Warner Losh <imp@FreeBSD.org> |
Merge from head at r201628.
# This hasn't been tested, and there are at least three bad commits # that need to be backed out before the branch will be stable again.
|
#
8d6960d0 |
| 05-Dec-2009 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
MFC r199895: Change memory managment from a fixed size array to a list. This is needed to avoid running into out of buffer situations where we cannot alloc a new buffer because we hit the array
MFC r199895: Change memory managment from a fixed size array to a list. This is needed to avoid running into out of buffer situations where we cannot alloc a new buffer because we hit the array size limit (ZBUF). Use a combined allocation for the struct and the actual data buffer to not increase the number of malloc calls. [1]
Defer initialization of zbuf until we actually need it.
Make sure the output buffer will be large enough in all cases.
Details discussed with: kib [1] Reviewed by: kib [1]
show more ...
|
#
6f443bec |
| 28-Nov-2009 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Change memory managment from a fixed size array to a list. This is needed to avoid running into out of buffer situations where we cannot alloc a new buffer because we hit the array size limit (ZBUF).
Change memory managment from a fixed size array to a list. This is needed to avoid running into out of buffer situations where we cannot alloc a new buffer because we hit the array size limit (ZBUF). Use a combined allocation for the struct and the actual data buffer to not increase the number of malloc calls. [1]
Defer initialization of zbuf until we actually need it.
Make sure the output buffer will be large enough in all cases.
Details discussed with: kib [1] Reviewed by: kib [1] MFC after: 6 days
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, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0 |
|
#
60727d8b |
| 07-Jan-2005 |
Warner Losh <imp@FreeBSD.org> |
/* -> /*- for license, minor formatting changes
|
Revision tags: release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs |
|
#
091d81d1 |
| 04-Oct-2002 |
Sam Leffler <sam@FreeBSD.org> |
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Acces
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols.
Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers.
Obtained from: openbsd
show more ...
|
#
9199c09a |
| 06-Jan-2010 |
Warner Losh <imp@FreeBSD.org> |
Merge from head at r201628.
# This hasn't been tested, and there are at least three bad commits # that need to be backed out before the branch will be stable again.
|
#
6f443bec |
| 28-Nov-2009 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Change memory managment from a fixed size array to a list. This is needed to avoid running into out of buffer situations where we cannot alloc a new buffer because we hit the array size limit (ZBUF).
Change memory managment from a fixed size array to a list. This is needed to avoid running into out of buffer situations where we cannot alloc a new buffer because we hit the array size limit (ZBUF). Use a combined allocation for the struct and the actual data buffer to not increase the number of malloc calls. [1]
Defer initialization of zbuf until we actually need it.
Make sure the output buffer will be large enough in all cases.
Details discussed with: kib [1] Reviewed by: kib [1] MFC after: 6 days
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, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0 |
|
#
60727d8b |
| 07-Jan-2005 |
Warner Losh <imp@FreeBSD.org> |
/* -> /*- for license, minor formatting changes
|
Revision tags: release/5.3.0_cvs, release/5.3.0, release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs |
|
#
091d81d1 |
| 04-Oct-2002 |
Sam Leffler <sam@FreeBSD.org> |
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Acces
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols.
Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers.
Obtained from: openbsd
show more ...
|