multimedia/navidrome: Return to pool
This is a useful piece of software but between Go and Node being
grotesque in their own ways I don't enjoy working on this any longer.
lagg: Remove the member pr_num from struct lagg_proto
It is set but never used. Remove it to avoid confusion and save a
little space.
While here, use designated initializers to initialize the LAGG protocol
table. That improves readability, and it will be safer to initialize the
table if we introduce new protocols in the future.
No functional change intended.
Reviewed by: glebius
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55124
lagg: Make the none protocol a first-class citizen
All the other protocols have corresponding start and input routines,
which are used in the fast path. Currently the none protocol is
treated specially. In the fast path it is checked to indicate whether
a working protocol is configured. There are two issues raised by this
design:
1. In production, other protocols are commonly used, but not the
none protocol. It smells like an overkill to always check it in the
fast path. It is unfair to other commonly used protocols.
2. PR 289017 reveals that there's a small window between checking the
protocol and calling lagg_proto_start(). lagg_proto_start() is possible
to see the none protocol and do NULL deferencing.
Fix them by making the none protocol a first-class citizen so that it
has start and input routines just the same as other protocols. Then we
can stop checking it in the fast path, since lagg_proto_start() and
[13 lines not shown]
mail/py-postfix-mta-sts-resolver: Update to 1.5.1
- switch to use 'USE_PYTHON=pep517'
- fix build error on Python 3.12[*] and confirmed on 3.13 and 3.14
PR: 292851 [*]
Reported by: portscout, Mike Andrews <mandrews at bit0.com> [*]
ChangeLogs: https://github.com/Snawoot/postfix-mta-sts-resolver/compare/v1.4.0...v1.5.1
Approved by: hrs (mentor, blanket)
www/angie*: Bump PORTREVISION after www/angie update
pkg does not honor RUN_DEPENDS versions, hence it fails to re-install
module packages after updates to www/angie. The only workaround is
bumping PORTREVISION for *all* modules.
PR: 292648
sysutils/py-nvitop: New port: Interactive NVIDIA-GPU process viewer
An interactive NVIDIA-GPU process viewer and beyond, the one-stop
solution for GPU process management.
WWW: https://github.com/XuehaiPan/nvitop
PR: 289083
Approved by: eduardo (mentor)
devel/py-nvidia-ml-py: New port: Python bindings to NVIDIA Management Library
This library provides a Python interface to GPU management and
monitoring functions for NVIDIA GPUs.
WWW: https://pypi.org/project/nvidia-ml-py/
PR: 289082
Approved by: eduardo (mentor)
sym(4): Use memcpy(9) instead of bcopy(9)
The overlap handling of bcopy(9) is not required in these cases.
Obtained from: BSD-licensed Linux sym53c8xx driver
(cherry picked from commit c8e9479c74a2af0f6c665e930091c163bf760fd5)
sym(4): Provide a DEVICE_DETACH(9) method
This also fixes sym_cam_free() to tear things down correctly, i. e. in
opposite order of setup, as well as sym_cam_attach() to not free devq
and SIM twice in the failure case.
(cherry picked from commit 518c01b31e96bbe8353a551885a61e7da6aed5f6)
sym(4): Map HCB memory as uncacheable also on x86
As part of making the chip-specific mix and match of different accesses
(DMA/bus space) work as desired, the intent is to map the HCB memory as
uncacheable. Prior to VM_MEMATTR_*, the !x86 way of indicating this to
bus_dmamem_alloc(9) was BUS_DMA_COHERENT. Then later on in 2db99100a4,
BUS_DMA_NOCACHE was hooked up to VM_MEMATTR_UNCACHEABLE for x86. As it
turns out, still as of today bus_dmamem_alloc(9) differs in this regard
across architectures. On arm, it still supports BUS_DMA_COHERENT only
for requesting uncacheable DMA and x86 still uses BUS_DMA_NOCACHE only.
On arm64 and riscv, BUS_DMA_COHERENT seems to effectively be an alias
for BUS_DMA_NOCACHE.
Thus, allocate the HCB memory with BUS_DMA_COHERENT | BUS_DMA_NOCACHE,
so we get uncacheable memory on all architectures including x86 and so
loads and stores from/to HCB won't get reordered. However, even on x86
we still need to use at least compiler barriers to achieve the desired
program order.
[12 lines not shown]
style(9): white space after ; and around binary operators
in for() loops. Also, use 'while', where only the
conditional test of 'for' was used.
Reviewed by: sjg
(cherry picked from commit 0050289464fa56ec79e060b8d8378b9ff7145a0e)
