[CIR][docs] C++ cleanup and exception handling design for CIR (#177625)
This change adds a document describing a new design for C++ cleanups and
exception handling in CIR.
Fix activating large_microzap on receive
This ensures that the in-memory state of the feature is recorded and
that `dsl_dataset_activate_feature` is not called when the feature
is already active.
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Austin Wise <AustinWise at gmail.com>
Closes #18143
Closes #18144
pyzfs: remove unimplemented libzfs_core functions from pyzfs
As per #9008, pyzfs implements and documents several functions that
would be very useful, but then try to call c functions in libzfs_core.
These functions do not exist in libzfs_core, and in the ~7 years of
ticket creation still do not exist in libzfs_core.
It seems unlikely that these functions will get implemented, though 2
years ago, ~5 years after that ticket lzc_get_props was implemented in
23a489a41167890cdd227366a5f950170df8cc9b which enabled get properties in
pyzfs. Sadly the first thing the pyzfs function for lzc_get_props does
is call _list, which cals lzc_list, which is not implmented. And the
functions to set or inherit properties are still missing.
Having these functions in pyzfs are misleading, footguns, and time
wasters when evaluating pyzfs.
Removing these functions from pyzfs means that _if_ these functions are
added in libzfs_core, then pyzfs will also need to re-implement these
[8 lines not shown]
workflows/commit-access-review.py: Print rate limit info
This script is hitting the rate limits, so this extra debugging output
should make it easier to figure out why.
Add .MAKE.VERSION as read-only variable
If MAKE_VERSION is defined, create ${.MAKE.VERSION} read-only
and retain ${MAKE_VERSION} for backwards compatibility.
[RISCV] Introduce a new syntax for processor-specific tuning feature strings (#175063)
This patch proposes new a tuning feature string format that helps users
to build a performance model by "configuring" an existing tune CPU,
along with its scheduling model. For example, this string
```
"sifive-x280:single-element-vec-fp64"
```
takes ``sifive-x280`` as the "base" tune CPU and configured it with
``single-element-vec-fp64``. This gives us a performance model that
looks exactly like that of ``sifive-x280``, except some of the 64-bit
vector floating point instructions now produce only a single element per
cycle due to ``single-element-vec-fp64``.
This string could eventually be used in places like ``-mtune`` at the
frontend. Right now, this patch only implements the parser part, which
is put under the TargetParser library.
The grammar for this string is:
[30 lines not shown]
