[orc-rt] Build RTTICrossDylibTestLib with ORC_RT_COMPILE_FLAGS (#223144)
Without ORC_RT_COMPILE_FLAGS, the test library builds with C++ RTTI on
by default. This leads to link errors when the ORC runtime is built with
C++ RTTI turned off.
[TableGen] Declare <TargetName>RegClassByHwModeTables in MC header (#223292)
When a target uses RegClassByHwMode in CompressPat, the generated
functions reference <TargetName>RegClassByHwModeTables.
Declare it under GET_INSTRINFO_MC_HELPER_DECLS (<Target>MCTargetDesc.h)
so it is visible to MC-layer users such as RISCVBaseInfo.cpp.
Fixes: 700d1f029d00 ("[TableGen] Support RegClassByHwMode in
CompressPat")
Convert the zfs.resource services to the typesafe pattern
## Context
`zfs.resource`, `zfs.resource.snapshot` and `zfs.resource.pool` were already half-converted: public methods carried `@api_method(check_annotations=True)` against models in `api/v27_0_0/`, and most in-process consumers already went through `call2`. What was missing was the structural half - the service classes still held the implementation. `resource_crud.py` and `snapshot_crud.py` were 800+ lines each, mixing a 117-line create pipeline, destroy validation, path helpers and per-method exception translation in with the API surface.
## Solution
**Lean shims delegating to module functions.** The three services keep only their `Config`, decorators and docstrings, and hand off to plain functions taking a `ServiceContext` - the same shape `ports`, `hardware` and `boot` already use. The logic lands in `resource_{query,create,destroy,ops}.py`, `snapshot_ops.py` and `prefetch_ops.py`. `create_rules.py`'s three pool-inspecting helpers now take a `ServiceContext` rather than an untyped `service`, and while touching that file it picks up `from __future__ import annotations` so its annotations stop being quoted strings.
**Each service sits in a module named after its namespace** - `resource.py`, `snapshot.py`, `prefetch.py`, `tier.py` - and `plugins/zfs/__init__.py` stays a docstring. That is deliberate and worth keeping: around 30 modules elsewhere import cheap leaves of this package (`exceptions`, `zvol_utils`, `utils`, `encryption`), and `test/integration/assets/pool.py` - which 173 test files pull in, on the client side - is one of them. With the service in `__init__.py`, `from middlewared.plugins.zfs.exceptions import ZFSPathNotFoundException` went from a `typing` import to 1438 modules including `middlewared.service` and the `truenas_pylibzfs` C extension, which `tests/requirements.txt` does not install. It is now 145 and pulls neither. `plugins/zpool/` already splits this way for the same reason.
**`zfs.resource.pool` becomes a sub-service** of `zfs.resource` instead of only being picked up by the plugin loader, which gives it a `self.s` path. That was the last thing forcing untyped string calls into this namespace - `pool.dedup`, the failover event handler and the `pool.post_import` hook all use `call2` now, and no string call to `zfs.resource*` survives outside the over-the-wire tests.
**`special_vdev_thresholds` moves to `utils/zfs/tier.py`.** It is pure arithmetic over two config fields and never belonged behind a plugin; `alert.source.zfs_tier` was importing it from `plugins.zfs.tier`, and alert sources are imported while `middlewared.service` is still initialising, so that pulled a plugin package in before `Service` was bound. Worth knowing that nothing static catches this class of breakage - mypy, lint, ruff and the whole unit suite were green on a tree that could not start.
`GenericCRUDService` is not an option here - its metaclass forces `filters`/`options` onto `query`, and `zfs.resource.query` takes a single request model. The `*_impl` methods also still return dicts, so nothing outside `plugins/zfs/` changes how it reads a result. Public wire shapes are identical, checked by replaying the full API surface on a test VM and diffing against the same run before the change.
Convert the zfs.resource services to the typesafe pattern
## Context
`zfs.resource`, `zfs.resource.snapshot` and `zfs.resource.pool` were already half-converted: public methods carried `@api_method(check_annotations=True)` against models in `api/v27_0_0/`, and most in-process consumers already went through `call2`. What was missing was the structural half - the service classes still held the implementation. `resource_crud.py` and `snapshot_crud.py` were 800+ lines each, mixing a 117-line create pipeline, destroy validation, path helpers and per-method exception translation in with the API surface.
## Solution
**Lean shims delegating to module functions.** The three services keep only their `Config`, decorators and docstrings, and hand off to plain functions taking a `ServiceContext` - the same shape `ports`, `hardware` and `boot` already use. `ZFSResourceService` moves to `plugins/zfs/__init__.py` and the snapshot service to `snapshot.py`; the logic lands in `resource_{query,create,destroy,ops}.py`, `snapshot_ops.py` and `prefetch_ops.py`. `create_rules.py`'s three pool-inspecting helpers now take a `ServiceContext` rather than an untyped `service`, and while touching that file it picks up `from __future__ import annotations` so its annotations stop being quoted strings.
**`zfs.resource.pool` becomes a sub-service** of `zfs.resource` instead of only being picked up by the plugin loader, which gives it a `self.s` path. That was the last thing forcing untyped string calls into this namespace - `pool.dedup`, the failover event handler and the `pool.post_import` hook all use `call2` now, and no string call to `zfs.resource*` survives outside the over-the-wire tests.
**`alert.source.zfs_tier` imports its plugin helper inside the method that uses it.** `middlewared.service` pulls in every alert source while it is still initialising, so a module-level import of a plugin package re-enters it before `Service` is bound and startup dies with an ImportError. Worth knowing that nothing static catches this: mypy, lint, ruff and the whole unit suite were green on the broken tree.
`GenericCRUDService` is not an option here - its metaclass forces `filters`/`options` onto `query`, and `zfs.resource.query` takes a single request model. The `*_impl` methods also still return dicts, so nothing outside `plugins/zfs/` changes how it reads a result. Public wire shapes are identical, checked by replaying the full API surface on a test VM and diffing against the same run before the change.
Enforce canmount=noauto across the whole apps dataset tree
## Problem
We only re-assert canmount=noauto on the five structural ix-apps datasets, never on the per-app volume datasets beneath app_mounts. If one of those ends up canmount=on - a hand-rolled zfs recv migration, or simply the ZFS default when a replication task runs without properties - the boot mount sweep mounts it while correctly skipping its noauto parent, and docker then mounts /mnt/.ix-apps straight over the top. The volume stays mounted but unreachable: zfs reports mounted=yes, stat returns ENOENT, and the container fails with "bind source path does not exist". Nothing recovers from this on its own, because the remount path only mounts datasets reporting mounted=no.
## Solution
Walk the whole apps tree in a single query and set canmount=noauto wherever it drifted. This is hooked into the docker start reconcile and, more importantly, into pool import right after the root dataset properties are normalized. The import hook is what actually prevents the breakage - it runs while the pool is imported but none of it is mounted yet, so the recursive mount that follows never encounters a canmount=on descendant. Pool import cannot fail because of it; a failure only logs a warning.
A box already in the broken state comes up clean on its next boot, but until then it still cannot unset its apps pool.
Convert the zfs.resource services to the typesafe pattern
## Context
`zfs.resource`, `zfs.resource.snapshot` and `zfs.resource.pool` were already half-converted: public methods carried `@api_method(check_annotations=True)` against models in `api/v27_0_0/`, and most in-process consumers already went through `call2`. What was missing was the structural half - the service classes still held the implementation. `resource_crud.py` and `snapshot_crud.py` were 800+ lines each, mixing a 117-line create pipeline, destroy validation, path helpers and per-method exception translation in with the API surface.
## Solution
**Lean shims delegating to module functions.** The three services keep only their `Config`, decorators and docstrings, and hand off to plain functions taking a `ServiceContext` - the same shape `ports`, `hardware` and `boot` already use. `ZFSResourceService` moves to `plugins/zfs/__init__.py` and the snapshot service to `snapshot.py`; the logic lands in `resource_{query,create,destroy,ops}.py`, `snapshot_ops.py` and `prefetch_ops.py`. `create_rules.py`'s three pool-inspecting helpers now take a `ServiceContext` rather than an untyped `service`.
**`zfs.resource.pool` becomes a sub-service** of `zfs.resource` instead of only being picked up by the plugin loader, which gives it a `self.s` path. That was the last thing forcing untyped string calls into this namespace - `pool.dedup`, the failover event handler and the `pool.post_import` hook all use `call2` now, and no string call to `zfs.resource*` survives outside the over-the-wire tests.
**`alert.source.zfs_tier` imports its plugin helper inside the method that uses it.** `middlewared.service` pulls in every alert source while it is still initialising, so a module-level import of a plugin package re-enters it before `Service` is bound and startup dies with an ImportError. Worth knowing that nothing static catches this: mypy, lint, ruff and the whole unit suite were green on the broken tree.
`GenericCRUDService` is not an option here - its metaclass forces `filters`/`options` onto `query`, and `zfs.resource.query` takes a single request model. The `*_impl` methods also still return dicts, so nothing outside `plugins/zfs/` changes how it reads a result. Public wire shapes are identical, checked by replaying the full API surface on a test VM and diffing against the same run before the change.
[libc][math] Fix fast path with small inputs for double precision sin/cos. (#221012)
https://github.com/llvm/llvm-project/pull/201748 added a fast branch for
small inputs to double precision sin/cos,
but the Ziv error bounds were too tight.
Fixes in this PR:
- Updating the Ziv error bounds to accommodate rounding errors.
- Copy binary64 sin/cos hard-to-round cases from the CORE-MATH project.
- Add python tool to convert textual hard to round cases to binary
files, and add those binary files.
- Add hard-to-round tests for double precision sin/cos in the exhaustive
test folder.
Fixes https://github.com/llvm/llvm-project/issues/220934.
Assisted-by: Gemini is used to generate the worst-case text-to-binary
tool.
mux proxy sockets also share in and out fds, so using this as a
heuristic to decide whether the connection is on an inet/inet6
socket is incorrect.
Fixes breakage in t-multiplex after recent pledge(2) changes where
the packet code would attempt to set TCP_NODELAY on a mux proxy
connection (which is AF_UNIX).
asmc.4: clean up/modernize manpage
- sysutils/ataidle is no more: it was superseded by camcontrol(8).
- Sort the models table alphabetically.
- Use the SPDX License ID instead of the longhand licensing tort in the
manpage header.
- Note that the driver has been heavily modified in 15.1 and later to
support additional platforms and functionality.
- Trim down SYNOPSIS.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D59470
apple_bce.4: add a basic manpage describing the driver
This new manpage describes what the apple_bce driver services, how the
driver is configured, and what Apple models the driver claims to
support.
Reviewed by: seuros
Differential Revision: https://reviews.freebsd.org/D59467
