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.

In D58851#1377474, @kib wrote:

In D58851#1377389, @rmacklem wrote:

In D58851#1377388, @kib wrote:

"pgrbwt" means that the function waits for the page busy state to pass. Often the reason for this state waiting forever is that the thread that waits already owns the busy state on the page.

Does the hang occur in the buffer strategy method?

Yes. Btw, I think the main use for this helper is in the server
where the vnode won't be an NFS one, so if this isn't easily
avoided, I wouldn't worry about it. (In other words, use the
helper in the NFS server, but not the NFS client.)

So in the strategy routine you effectively have the same algorithm applied already by the buf layer. You can use b_pages[] directly.

The main change is using b_pages directly for read/write.

Alos please change the first line of the commit message to

LinuxKPI: firmware: ....

Landed as part of D52149 dc74f3003c2d

Landed as part of D52149 dc74f3003c2d

Landed as part of D52149 dc74f3003c2d

Landed as part of D52149 dc74f3003c2d

OBE in D51388 landed in aed44717a160

better functionality landed in main

Superceded by D54095 and landed as 848602856f49

Landed as 35b2e888ef0f

Landed as bd4a4e46ceac

This turned out to be a bad idea.

D46048 and D51391 largely address this issue.