#
e9ac4169 |
| 15-Jul-2024 |
Warner Losh <imp@FreeBSD.org> |
Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
|
Revision tags: release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
031beb4e |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
Revision tags: release/13.2.0 |
|
#
dddb1aec |
| 22-Mar-2023 |
John Baldwin <jhb@FreeBSD.org> |
sys: Retire OPENZFS_CWARNFLAGS now that it is empty.
Reviewed by: markj, emaste Differential Revision: https://reviews.freebsd.org/D39217
|
Revision tags: release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
d021434a |
| 27-Dec-2020 |
Ryan Libby <rlibby@FreeBSD.org> |
openzfs: fix gcc kernel module builds
- Suppress -Wredundant-decls. Ultimately this warning is harmless in any case, and it does not look like there is a simple way to avoid redundant declar
openzfs: fix gcc kernel module builds
- Suppress -Wredundant-decls. Ultimately this warning is harmless in any case, and it does not look like there is a simple way to avoid redundant declarations in this case without a lot of header pollution (e.g. having openzfs's shim param.h pulling in sys/kernel.h for hz). - Suppress -Wnested-externs, which is useless anyway.
Unfortunately it was not sufficient just to modify OPENZFS_CFLAGS, because the warning suppressions need to appear on the command line after they are explicitly enabled by CWARNFLAGS from sys/conf/kern.mk, but OPENZFS_CFLAGS get added before due to use of -I for the shims.
Reviewed by: markj Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D27685
show more ...
|
Revision tags: release/12.2.0 |
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
9e5787d2 |
| 25-Aug-2020 |
Matt Macy <mmacy@FreeBSD.org> |
Merge OpenZFS support in to HEAD.
The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort.
I would a
Merge OpenZFS support in to HEAD.
The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort.
I would advise against doing 'zpool upgrade' or creating indispensable pools using new features until this change has had a month+ to soak.
Work on merging FreeBSD support in to what was at the time "ZFS on Linux" began in August 2018. I first publicly proposed transitioning FreeBSD to (new) OpenZFS on December 18th, 2018. FreeBSD support in OpenZFS was finally completed in December 2019. A CFT for downstreaming OpenZFS support in to FreeBSD was first issued on July 8th. All issues that were reported have been addressed or, for a couple of less critical matters there are pull requests in progress with OpenZFS. iXsystems has tested and dogfooded extensively internally. The TrueNAS 12 release is based on OpenZFS with some additional features that have not yet made it upstream.
Improvements include: project quotas, encrypted datasets, allocation classes, vectorized raidz, vectorized checksums, various command line improvements, zstd compression.
Thanks to those who have helped along the way: Ryan Moeller, Allan Jude, Zack Welch, and many others.
Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D25872
show more ...
|
Revision tags: release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0, release/10.4.0, release/11.1.0 |
|
#
ea1e967c |
| 19-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r318380 through r318559.
|
#
5c63f261 |
| 18-May-2017 |
Enji Cooper <ngie@FreeBSD.org> |
Normalize SYSDIR on SRCTOP instead of .CURDIR
This is being done to simplify pathing for CFLAGS and source files.
MFC after: 2 weeks Sponsored by: Dell EMC Isilon
|
#
1811d6bf |
| 29-Mar-2017 |
Robert Watson <rwatson@FreeBSD.org> |
Add an experimental DTrace audit provider, which allows users of DTrace to instrument security event auditing rather than relying on conventional BSM trail files or audit pipes:
- Add a set of per-e
Add an experimental DTrace audit provider, which allows users of DTrace to instrument security event auditing rather than relying on conventional BSM trail files or audit pipes:
- Add a set of per-event 'commit' probes, which provide access to particular auditable events at the time of commit in system-call return. These probes gain access to audit data via the in-kernel audit_record data structure, providing convenient access to system-call arguments and return values in a single probe.
- Add a set of per-event 'bsm' probes, which provide access to particular auditable events at the time of BSM record generation in the audit worker thread. These probes have access to the in-kernel audit_record data structure and BSM representation as would be written to a trail file or audit pipe -- i.e., asynchronously in the audit worker thread.
DTrace probe arguments consist of the name of the audit event (to support future mechanisms of instrumenting multiple events via a single probe -- e.g., using classes), a pointer to the in-kernel audit record, and an optional pointer to the BSM data and its length. For human convenience, upper-case audit event names (AUE_...) are converted to lower case in DTrace.
DTrace scripts can now cause additional audit-based data to be collected on system calls, and inspect internal and BSM representations of the data. They do not affect data captured in the audit trail or audit pipes configured in the system. auditd(8) must be configured and running in order to provide a database of event information, as well as other audit configuration parameters (e.g., to capture command-line arguments or environmental variables) for the provider to operate.
Reviewed by: gnn, jonathan, markj Sponsored by: DARPA, AFRL MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D10149
show more ...
|