LLVM/project 017f9dellvm/include/llvm/ProfileData ETMTraceDecoder.h, llvm/lib/ProfileData ETMTraceDecoder.cpp

Revert "[llvm-profgen] Add support for ETM trace decoding (#191584)"

This reverts commit e3bd61890e68303a33fdd33fbdd9abeda1037450.
DeltaFile
+0-251llvm/lib/ProfileData/ETMTraceDecoder.cpp
+33-68llvm/tools/llvm-profgen/llvm-profgen.cpp
+18-71llvm/tools/llvm-profgen/PerfReader.cpp
+0-81llvm/test/tools/llvm-profgen/etm-arch.test
+0-48llvm/test/tools/llvm-profgen/Inputs/etm-opencsd.yaml
+0-46llvm/include/llvm/ProfileData/ETMTraceDecoder.h
+51-5658 files not shown
+69-66714 files

LLVM/project 5064b93clang/lib/DependencyScanning InProcessModuleCache.cpp

[clang][deps] Always initialize module cache out params (#194082)

We did not initialize the out parameters in #192347, causing the
"sanitizer-x86_64-linux-fast" bot to complain with:

```
SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1525:63 in compileModuleImpl(clang::CompilerInstance&, clang::SourceLocation, clang::SourceLocation, clang::Module*, clang::ModuleFileName)
Exiting
==clang==3084515==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x586360f7a604 in compileModuleImpl(clang::CompilerInstance&, clang::SourceLocation, clang::SourceLocation, clang::Module*, clang::ModuleFileName) /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1525:63
    #1 <...>
```

This PR should fix that.
DeltaFile
+4-0clang/lib/DependencyScanning/InProcessModuleCache.cpp
+4-01 files

LLVM/project e3bd618llvm/include/llvm/ProfileData ETMTraceDecoder.h, llvm/lib/ProfileData ETMTraceDecoder.cpp

[llvm-profgen] Add support for ETM trace decoding (#191584)

This patch introduces ETMReader to llvm-profgen,
enabling the reconstruction of execution profiles from ETM formatted
trace data.

- Integrate OpenCSD (CoreSight Decoding Library) as an optional
dependency via the LLVM_ENABLE_OPENCSD flag.
- Implement ETMTraceDecoder in ProfileData to interface with OpenCSD.
- Implement ETMReader, which uses hardware configuration and ELF memory
mapping to decode instruction traces.
- Add the --etm command-line option to specify raw trace inputs.
- Add the --target-triple command-line option to override the target
architecture for the binary.

The implementation targets microcontroller-class (Cortex-M) devices
based on the binary's target triple.

RFC:
https://discourse.llvm.org/t/rfc-add-etm-trace-support-to-llvm-profgen/90525
DeltaFile
+251-0llvm/lib/ProfileData/ETMTraceDecoder.cpp
+68-33llvm/tools/llvm-profgen/llvm-profgen.cpp
+71-18llvm/tools/llvm-profgen/PerfReader.cpp
+81-0llvm/test/tools/llvm-profgen/etm-arch.test
+48-0llvm/test/tools/llvm-profgen/Inputs/etm-opencsd.yaml
+46-0llvm/include/llvm/ProfileData/ETMTraceDecoder.h
+565-518 files not shown
+667-6914 files

LLVM/project 18fc429lld/test/MachO arm64-thunks.s

add missing test checks
DeltaFile
+21-3lld/test/MachO/arm64-thunks.s
+21-31 files

LLVM/project 327f027offload/plugins-nextgen/amdgpu/src rtl.cpp

[offload] Fix compilation (#194081)
DeltaFile
+2-2offload/plugins-nextgen/amdgpu/src/rtl.cpp
+2-21 files

LLVM/project ca934b8llvm/include/llvm/DWARFLinker/Classic DWARFStreamer.h DWARFLinker.h, llvm/lib/DWARFLinker/Classic DWARFLinker.cpp DWARFStreamer.cpp

[dsymutil] Report error when section offsets exceed DWARF32 limit (#193867)

When linking very large binaries, debug section offsets can exceed the 4
GB DWARF32 limit. Previously this caused an assertion in
MCStreamer::emitIntValue when trying to emit an overflowing
DW_FORM_sec_offset value.

Detect the overflow at the point where section offsets are patched in
DWARFStreamer (for .debug_ranges, .debug_rnglists, .debug_loc,
.debug_loclists) and in DWARFLinker (for .debug_line and .debug_addr).

rdar://107413300
DeltaFile
+85-39llvm/lib/DWARFLinker/Classic/DWARFLinker.cpp
+39-17llvm/lib/DWARFLinker/Classic/DWARFStreamer.cpp
+23-14llvm/include/llvm/DWARFLinker/Classic/DWARFStreamer.h
+13-13llvm/include/llvm/DWARFLinker/Classic/DWARFLinker.h
+160-834 files

LLVM/project 5536a4cllvm/lib/MC MCInstrDesc.cpp, llvm/lib/Target/AArch64 AArch64InstrInfo.cpp

[LFI][AArch64] Add rewrites for control flow (#192602)

Adds LFI rewrites for control flow instructions (indirect branches and
returns). Indirect branches must go through `x28`, which is always
guaranteed to hold a sandbox address. Modifications to `x30` must guard
`x30` afterwards, to uphold the invariant that `x30` always holds a
sandbox address. As a result, bare return instructions can be used
without any additional rewrites.
DeltaFile
+57-0llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCLFIRewriter.cpp
+21-4llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
+25-0llvm/test/MC/AArch64/LFI/return.s
+21-0llvm/test/MC/AArch64/LFI/branch.s
+9-3llvm/lib/MC/MCInstrDesc.cpp
+10-0llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCLFIRewriter.h
+143-74 files not shown
+156-1110 files

LLVM/project cb5bfb1clang/lib/ScalableStaticAnalysisFramework/Analyses/PointerFlow PointerFlowExtractor.cpp PointerFlowFormat.cpp, clang/lib/ScalableStaticAnalysisFramework/Analyses/UnsafeBufferUsage UnsafeBufferUsageFormat.cpp

address comments
DeltaFile
+218-202clang/lib/ScalableStaticAnalysisFramework/Analyses/PointerFlow/PointerFlowExtractor.cpp
+7-10clang/lib/ScalableStaticAnalysisFramework/Analyses/PointerFlow/PointerFlowFormat.cpp
+3-1clang/lib/ScalableStaticAnalysisFramework/Analyses/UnsafeBufferUsage/UnsafeBufferUsageFormat.cpp
+228-2133 files

LLVM/project d1c9b4amlir/lib/Conversion/XeVMToLLVM XeVMToLLVM.cpp, mlir/test/Conversion/XeVMToLLVM xevm_mx-to-llvm.mlir

[MLIR][XeVM] Update API usage. Some OpenCL APIs are not supported. (#193320)

In such case, use internal APIs for Intel Graphics Compiler directly.
DeltaFile
+24-10mlir/lib/Conversion/XeVMToLLVM/XeVMToLLVM.cpp
+12-12mlir/test/Conversion/XeVMToLLVM/xevm_mx-to-llvm.mlir
+7-5mlir/test/Integration/Dialect/XeVM/GPU/xevm_block_scaled_dpas_bf8.mlir
+43-273 files

LLVM/project d0c91declang/test/Driver linux-multilib.yaml mingw-multilib.yaml, clang/test/Driver/Inputs/multilib_linux_tree/usr/bin .keep

[clang][NFC] Linux/Windows Multilib Include Path Tests (#193869)

This adds checks to the tests to show how the include path is changed by
the multilib logic for Linux/Windows added in commit
78820cb91605693b7d768be4ebc8b66181d3e9c3.

Assisted By: Claude
DeltaFile
+9-0clang/test/Driver/linux-multilib.yaml
+9-0clang/test/Driver/mingw-multilib.yaml
+0-0clang/test/Driver/Inputs/multilib_linux_tree/usr/include/x86_64-unknown-linux-gnu/.keep
+0-0clang/test/Driver/Inputs/multilib_linux_tree/usr/bin/.keep
+0-0clang/test/Driver/Inputs/multilib_linux_tree/usr/include/x86_64-unknown-linux-gnu/debug/.keep
+0-0clang/test/Driver/Inputs/multilib_linux_tree/usr/include/x86_64-unknown-linux-gnu/noexcept/.keep
+18-06 files not shown
+18-012 files

LLVM/project d14866fllvm/utils/gn/secondary/clang/lib/ScalableStaticAnalysisFramework/Analyses BUILD.gn

gn build: Port a4538a3ad902



Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/194077
DeltaFile
+1-0llvm/utils/gn/secondary/clang/lib/ScalableStaticAnalysisFramework/Analyses/BUILD.gn
+1-01 files

FreeBSD/src 0f7b8f7sys/dev/ena ena_datapath.c ena.h

ena: Budget rx descriptors, not packets

We had ENA_RX_BUDGET = 256 in order to allow up to 256 received
packets to be processed before we do other cleanups (handling tx
packets and, critically, refilling the rx buffer ring).  Since the
ring holds 1024 buffers by default, this was fine for normal packets:
We refill the ring when it falls below 7/8 full, and even with a large
burst of incoming packets allowing it to fall by another 1/4 before we
consider refilling the ring still leaves it at 7/8 - 1/4 = 5/8 full.

With jumbos, the story is different: A 9k jumbo (as is used by default
within the EC2 network) consumes 3 descriptors, so a single rx cleanup
pass can consume 3/4 of the default-sized rx ring; if the rx buffer
ring wasn't completely full before a packet burst arrives, this puts
us perilously close to running out of rx buffers.

This precise failure mode has been observed on some EC2 instance types
within a Cluster Placement Group, resulting in the nominal 10 Gbps
single-flow throughput between instances dropping to ~100 Mbps as a

    [19 lines not shown]
DeltaFile
+10-3sys/dev/ena/ena_datapath.c
+2-2sys/dev/ena/ena.h
+12-52 files

FreeBSD/src f6d2c85sys/dev/ena ena_datapath.c

ena: Adjust ena_[rt]x_cleanup to return bool

The ena_[rt]x_cleanup functions are limited internally to a maximum
number of packets; this ensures that TX doesn't starve RX (or vice
versa) and also attempts to ensure that we get a chance to refill
the RX buffer ring before the device runs out of buffers and starts
dropping packets.

Historically these functions have returned the number of packets which
they processed which ena_cleanup compares to their respective budgets
to decide whether to reinvoke them.  This is unnecessary complication;
since the precise number of packets processed is never used, adjust
the APIs of those functions to return a bool indicating if they want
to be reinvoked (aka if they hit their limits).

Since ena_tx_cleanup now only uses work_done if diagnostics are
enabled (ena_log_io macros to nothing otherwise) eliminate that
variable and pass its value (ENA_TX_BUDGET - budget) to ena_log_io
directly.

    [7 lines not shown]
DeltaFile
+12-14sys/dev/ena/ena_datapath.c
+12-141 files

FreeBSD/ports 3fa5c27astro/qmapshack distinfo Makefile, astro/qmapshack/files patch-src_qmapshack_setup_CAppSetupLinux.cpp patch-src_qmaptool_setup_CAppSetupLinux.cpp

astro/qmapshack: update to 1.20.2

Release Notes:
  https://github.com/Maproom/qmapshack/releases/tag/V_1.20.2
DeltaFile
+13-5astro/qmapshack/files/patch-src_qmapshack_setup_CAppSetupLinux.cpp
+13-5astro/qmapshack/files/patch-src_qmaptool_setup_CAppSetupLinux.cpp
+3-3astro/qmapshack/distinfo
+1-2astro/qmapshack/Makefile
+30-154 files

Linux/linux 27d128ckernel/trace ring_buffer.c

Merge tag 'trace-ring-buffer-v7.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull ring-buffer fix from Steven Rostedt:

 - Fix accounting of persistent ring buffer rewind

   On boot up, the head page is moved back to the earliest point of the
   saved ring buffer. This is because the ring buffer being read by user
   space on a crash may not save the part it read. Rewinding the head
   page back to the earliest saved position helps keep those events from
   being lost.

   The number of events is also read during boot up and displayed in the
   stats file in the tracefs directory. It's also used for other
   accounting as well. On boot up, the "reader page" is accounted for
   but a rewind may put it back into the buffer and then the reader page
   may be accounted for again.

   Save off the original reader page and skip accounting it when

    [4 lines not shown]
DeltaFile
+7-6kernel/trace/ring_buffer.c
+7-61 files

Linux/linux f3e3dbcblock blk.h bio.c, drivers/block ublk_drv.c zloop.c

Merge tag 'block-7.1-20260424' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull block fixes from Jens Axboe:

 - Series for zloop, fixing a variety of issues

 - t10-pi code cleanup

 - Fix for a merge window regression with the bio memory allocation mask

 - Fix for a merge window regression in ublk, caused by an issue with
   the maple tree iteration code at teardown

 - ublk self tests additions

 - Zoned device pgmap fixes

 - Various little cleanups and fixes


    [22 lines not shown]
DeltaFile
+80-43drivers/block/ublk_drv.c
+59-64drivers/block/zloop.c
+103-0tools/testing/selftests/ublk/test_integrity_03.sh
+13-12include/linux/t10-pi.h
+21-0block/blk.h
+6-5block/bio.c
+282-12455 files not shown
+347-18761 files

FreeBSD/ports 446014fsecurity/nss distinfo Makefile

security/nss: update to 3.123.1

Announcement:
  https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/IXfP0olxGT0
(cherry picked from commit b9183d42817a217f2cc71e12877e2fb270f68a0c)
DeltaFile
+3-3security/nss/distinfo
+1-1security/nss/Makefile
+4-42 files

FreeBSD/ports b9183d4security/nss distinfo Makefile

security/nss: update to 3.123.1

Announcement:
  https://groups.google.com/a/mozilla.org/g/dev-tech-crypto/c/IXfP0olxGT0
DeltaFile
+3-3security/nss/distinfo
+1-1security/nss/Makefile
+4-42 files

FreeBSD/src f31e6b1sys/dev/speaker spkr.c

speaker(4): move static data to text

Make this data const (it doesn't change) which will also move it to
a text section.

Signed-off-by: Raphael Poss <knz at thaumogen.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1922
DeltaFile
+2-2sys/dev/speaker/spkr.c
+2-21 files

FreeBSD/src 45a12d8sys/dev/speaker spkr.c

Revert "speaker(4): move static data to bss"

This reverts commit 690ef95b3354ac7a80aa469fa7a8f15f07962f83.

The commit message was wrong.
DeltaFile
+2-2sys/dev/speaker/spkr.c
+2-21 files

Linux/linux fa58e6eio_uring memmap.c register.c

Merge tag 'io_uring-7.1-20260424' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull io_uring fixes from Jens Axboe:

 - Fix for a NOMMU bug with io_uring, where NOMMU doesn't grab page refs
   at mmap time. NOMMU also has entirely broken FOLL_PIN support, yet
   here we are

 - A few fixes covering minor issues introduced in this merge window

 - data race annotation to shut up KCSAN for when io-wq limits are
   applied

 - A nospec addition for direct descriptor file updating. Rest of the
   direct descriptor path already had this, but for some reason the
   update did not. Now they are all the same

 - Various minor defensive changes that claude identified and suggested
   terrible fixes for, turned into actually useful cleanups:

    [47 lines not shown]
DeltaFile
+45-1io_uring/memmap.c
+26-6io_uring/register.c
+11-4io_uring/tctx.c
+7-2io_uring/rsrc.h
+4-2io_uring/poll.c
+4-1io_uring/zcrx.c
+97-165 files not shown
+109-2211 files

LLVM/project 2b43da5llvm/lib/Target/AArch64 AArch64StackTaggingPreRA.cpp AArch64.h

[NewPM] Port for AArch64StackTaggingPreRA (#194021)

This patch migrates the AArch64StackTaggingPreRA pass to the New Pass
Manager.

Following the standard pattern for pass migrations:
- The core logic has been extracted into a standalone
AArch64StackTaggingPreRAImpl class.
- A new pass manager wrapper (AArch64StackTaggingPreRAPass) has been
created.
- The legacy pass manager wrapper has been renamed to
AArch64StackTaggingPreRALegacy and updated to call the shared
implementation.
- The pass is registered in AArch64PassRegistry.def to make it available
to the New PM.
DeltaFile
+40-15llvm/lib/Target/AArch64/AArch64StackTaggingPreRA.cpp
+9-2llvm/lib/Target/AArch64/AArch64.h
+2-2llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
+1-0llvm/lib/Target/AArch64/AArch64PassRegistry.def
+52-194 files

LLVM/project 2826b51llvm/docs AMDGPUUsage.rst, llvm/lib/Target/AMDGPU AMDGPUAsmPrinter.cpp

[AMDGPU] Add `.amdgpu.info` section for per-function metadata

AMDGPU object linking requires the linker to propagate resource usage
(registers, stack, LDS) across translation units. To support this, the compiler
must emit per-function metadata and call graph edges in the relocatable object
so the linker can compute whole-program resource requirements.

This PR introduces a `.amdgpu.info` ELF section using a tagged, length-prefixed
binary format: each entry is encoded as:

```
[kind: u8] [len: u8] [payload: <len> bytes]
```

A function scope is opened by an `INFO_FUNC` entry (containing a symbol
reference), followed by per-function attributes (register counts, flags, private
segment size) and relational edges (direct calls, LDS uses, indirect call
signatures). String data such as function type signatures is stored in a
companion `.amdgpu.strtab` section.

    [4 lines not shown]
DeltaFile
+221-0llvm/test/CodeGen/AMDGPU/lds-link-time-codegen-typeid.ll
+179-0llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
+155-2llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
+126-0llvm/test/MC/AMDGPU/amdgpu-info-roundtrip.s
+113-0llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp
+106-0llvm/docs/AMDGPUUsage.rst
+900-29 files not shown
+1,209-1415 files

FreeBSD/src 861deacsys/arm/broadcom/bcm2835 bcm2838_xhci.c

Fix xhci detection on Raspberry Pi 400

If you use the FreeBSD pre-build Raspberry Pi image, it does not include
the specific .dtb file for the Raspberry Pi 400. On this hardware, it
will fall back to attempting to load the Raspberry Pi 4 .dtb file
instead.

The Pi 4 .dtb file reports the board compatible name as
"raspberrypi,4-model-b" The Pi 400 .dtb file reports the board
compatible name as "raspberrypi,400" However, it's even better to
use the generic name.

When using the official Pi 400 .dtb file from the Raspberry Pi Firmware
collection, the FreeBSD xhci driver currently fails to recognize this,
and thus fails to initialize the xhci device. This means no external
USB, or internal USB (which feeds the build-in keyboard)

The official Raspberry Pi FreeBSD image has been working on the Pi 400
"on accident" simply because it didn't include the Pi 400 .dtb file

    [11 lines not shown]
DeltaFile
+2-2sys/arm/broadcom/bcm2835/bcm2838_xhci.c
+2-21 files

LLVM/project f6463b7clang/lib/ScalableStaticAnalysisFramework/Analyses/EntityPointerLevel EntityPointerLevelFormat.cpp EntityPointerLevel.cpp, clang/lib/ScalableStaticAnalysisFramework/Analyses/PointerFlow PointerFlowFormat.cpp PointerFlow.cpp

Move serialization code to *Format.cpp files
DeltaFile
+113-0clang/lib/ScalableStaticAnalysisFramework/Analyses/PointerFlow/PointerFlowFormat.cpp
+106-0clang/lib/ScalableStaticAnalysisFramework/Analyses/UnsafeBufferUsage/UnsafeBufferUsageFormat.cpp
+0-96clang/lib/ScalableStaticAnalysisFramework/Analyses/PointerFlow/PointerFlow.cpp
+0-88clang/lib/ScalableStaticAnalysisFramework/Analyses/UnsafeBufferUsage/UnsafeBufferUsage.cpp
+58-0clang/lib/ScalableStaticAnalysisFramework/Analyses/EntityPointerLevel/EntityPointerLevelFormat.cpp
+0-42clang/lib/ScalableStaticAnalysisFramework/Analyses/EntityPointerLevel/EntityPointerLevel.cpp
+277-2261 files not shown
+280-2267 files

LLVM/project 2953eacllvm/docs LangRef.rst, llvm/include/llvm/IR DataLayout.h

[DataLayout] Add null pointer value infrastructure

Add support for specifying the null pointer bit representation per address space
in DataLayout via new pointer spec flags:
- 'z': null pointer is all-zeros
- 'o': null pointer is all-ones

When neither flag is present, the address space inherits the default set by the
new 'N<null-value>' top-level specifier ('Nz' or 'No'). If that is also absent,
the null pointer value is unknown and LLVM will not fold based on it.

No target DataLayout strings are updated in this change. This is pure
infrastructure for a future ConstantPointerNull semantic change to support
targets with non-zero null pointers (e.g. AMDGPU).
DeltaFile
+153-1llvm/unittests/IR/DataLayoutTest.cpp
+64-6llvm/lib/IR/DataLayout.cpp
+30-1llvm/include/llvm/IR/DataLayout.h
+17-1llvm/docs/LangRef.rst
+3-3llvm/test/Linker/2003-08-24-InheritPtrSize.ll
+267-125 files

LLVM/project 17b5b21llvm/lib/MC MCSection.cpp, llvm/test/MC/AMDGPU reloc-directive.s

[𝘀𝗽𝗿] initial version

Created using spr 1.3.6-beta.1
DeltaFile
+23-0llvm/test/MC/X86/reloc-directive-tlsgd.s
+19-1llvm/lib/MC/MCSection.cpp
+6-6llvm/test/MC/Mips/reloc-directive-label-offset.s
+5-5llvm/test/MC/SystemZ/reloc-directive.s
+4-4llvm/test/MC/Mips/reloc-directive.s
+3-3llvm/test/MC/AMDGPU/reloc-directive.s
+60-1915 files not shown
+101-5721 files

LLVM/project 3c5b94flld/MachO ConcatOutputSection.cpp

add updateBranchTargetToThunk
DeltaFile
+22-24lld/MachO/ConcatOutputSection.cpp
+22-241 files

FreeNAS/freenas 4384f3dsrc/middlewared/middlewared/plugins/network_ global_config.py, tests/api2 test_service_announcement.py

Simplify restart

(cherry picked from commit 29d8b900ffc742c49de603094fa20a78a026da54)
DeltaFile
+146-20tests/api2/test_service_announcement.py
+12-18src/middlewared/middlewared/plugins/network_/global_config.py
+158-382 files

FreeNAS/freenas 8a06b8esrc/middlewared/middlewared/etc_files/local/avahi/services ADISK.service.py, src/middlewared/middlewared/etc_files/local/truenas-discovery truenas-discoveryd.conf.py

Use truenas-discovery service

This commit replaces avahi, wsdd, and netbios services with a
unified truenas-discovery service. This simplifies the middleware
implementation of these services. Tests are adjusted so that we
have more direct testing that middleware configuration changes
are reflected in the in-memory running configuration of the
truenas-discoveryd daemon. During testing / validation I
discovered that there were some escape avenues whereby the
configuration may not be properly reloaded after netbios name
or workgroup changes.

(cherry picked from commit 509ea9d1256d707185f1fb18d30410fef0ef2684)
DeltaFile
+0-479tests/api2/test_310_service_announcement.py
+463-0tests/api2/test_service_announcement.py
+13-160src/middlewared/middlewared/utils/mdns.py
+63-0src/middlewared/middlewared/etc_files/local/truenas-discovery/truenas-discoveryd.conf.py
+0-63src/middlewared/middlewared/etc_files/local/avahi/services/ADISK.service.py
+58-0src/middlewared/middlewared/etc_files/local/truenas-discovery/services.d/ADISK.conf.py
+597-70228 files not shown
+814-1,03734 files