@bz: (a) The native type can't be reused. It is struct uuid, with time_low/time_mid/... fields, which ACPI and GEOM use, while Linux's uuid_t is a raw 16-byte array (.b[]) that drivers index and memcpy. (b) In the kernel, sys/uuid.h provides only struct uuid; its uuid_t typedef is userland-only. OpenZFS's SPL defines its own kernel uuid_t, but ZFS never includes LinuxKPI headers, so nothing clashes today.

Updated as wulf suggested: the definition sits next to guid_t, and uuid_t is linux_uuid_t behind a macro.

<sys/systm.h> now follows <sys/param.h>, as wulf asked; nothing else.

native code, as wulf asked; pci_ids.h is no longer touched.

1. rebase main
2. copyright fixup as suggested by @imp
3. sbrk test conditional build refinement, as separate differential:

https://reviews.freebsd.org/D60357, https://reviews.freebsd.org/D60358

4. misc fixes suggested by @shipujin.t_gmail.com

Please ask Peter to do the full stress2 run

hm, whats left before we can land this?

Add assert in addition to stating the locking mode for mnt_susp_owner

@kib OK, done. ffs_sync_alloc() is gone, and an allocating O_SYNC/O_DSYNC write finishes with ffs_syncvnode() again, as in the revision before last (DATA_ONLY for O_DSYNC, still only when the write changed i_blocks).

pmap_enter() hardcodes PTE_CC and ignores m->md.pv_memattr.

Elaborate more about locking.

In D60275#1384110, @wulf wrote:

firstly we'd be changing the KBI (I think) on systems where sizeof(unsigned int) != size_t.

crc16() is static inline. It should not have KBI unless maybe exotic cases like -O0 or execution via pointer.

To answer your question, the ti_edma3tc instances never touched that global, it only ever held the one channel controller.

Updated to use the new ti_edma3 interface from D59124.

In D58851#1384275, @rmacklem wrote:

I do have a question w.r.t. read on the NFS server.
I am guessing that the NFS code needs to VOP_GETATTR()
and use va_size to determine where the file ends in the last
page.
Is that correct?

Add comment.

This adds copyright information for lib/libexpat (aka libbsdxml).

In D56474#1380498, @stephane.rochoy_stormshield.eu wrote:

In D56474#1379752, @khorben wrote:

The reasoning is to have one SBOM per package and per third-party project. In practice this is not really possible, because if a project exposes a library in addition to itself (e.g., libssl and libcrypto for OpenSSL) we still need to easily be able to express the dependency on OpenSSL, or at least on a specific component of OpenSSL.

In the current version of this proposal for the generation framework, dependencies are tracked automatically. When including internal libraries in this mechanism, a single project like wpa_supplicant gets 16 SBOM files in addition to itself (e.g., libwpatls, libwpapasn, libwpadrivers...). From what I understand of the INTERNALLIB flag, these libraries are not meant to be re-used by other projects. Therefore I have reflected this here, by excluding such libraries from the automatic dependency list (by using _INTERNALLIBS as per src.libnames.mk).

In this example, wpa_supplicant still gets its corresponding SBOM, and is shipped in a single package without an additional library package, so I think it makes sense to stick to a single SBOM.

With this said, if your project wants to express a dependency on an internal library specifically, it is possible to override SBOM_REQUIRES to list it there. As things currently are, this will probably require the creation of a corresponding .pc file for this library, which can be done with the creation of a Makefile.sbom file in the directory of that library.

Let me know if this is still not clear, if it looks good enough for now, or if I should modify anything in any way.

Do you know if INTERNALLIBS also encompass the libprivate* libs? Because this libs should be exposed in the SBOM IMO.