The num namespaces changes should be separate

I have some suggestions

I asked as a question to learn the latest. I'm cool with what's there or c11 usage

Not sure you need to set the taskqueue to NULL, but it won't hurt.

Do you have any way to provoke the race that lead to this commit?

fix issues that devin highlighted

This looks good. I had intended to commit this when submitted, but it fall off my radar.
I did have one question: when validating the power states, you compare against 32 instead of the number of power states in the card. It seems like you should do the latter, is there any reason, other than the max possible power state, that you did this? I suppose the drive will reject bad states when the set feature is sent, but maybe it's better to validate where I flagged.

devin's review

oops

Thanks for the the pre-existing typos too. Technically out of scope, but I'll fold them in.

I'm good with the text and mfc plan.

Fix AI overly verbose comment I missed in prior passes.

This looks fine as is. I usually tweak .Dd dates when I notice :) But this one should be fixed.

Generally i like it. One question to consider.

So this is OK. A better thing would be to just drop the CAM lock. That should be safe. However, it's going to be super rare we can't allocate here. Can you commit this as is, but file a bug and assign it to me. The bug should be 'investigate dropping CAM lock for AC_GETDEV_CHANGED in nda' and I'll not forget about it that way.

If you have a time for the refactor I requested, that would be idea.
If not, this is OK enough as it is with the ns == 0 check, since that's not a valid namespace.

In D58383#1339358, @emaste wrote:

EFI_MEMORY_ATTRIBUTE_PROTOCOL is the interface to change mapping

In D57741#1339463, @thebugfixers_pm.me wrote:

In D57741#1339112, @bnovkov wrote:

Why was this review closed? The issue wasn't resolved in the meantime and I see no reason not to land this.

I cannot remember, but looking at the timestamp, my guess is it was perhaps related to 'politics' I experienced on another diff where I was basically told in no uncertain terms 'its always been this way and we're not changing it' despite the POSIX standards having quite clearly moved on. This is all despite the case that two reviewers were (as far as I could tell) very happy with the concept of the proposed changes subject to minor revision and then I was basically shouted out of the room by the third. I have better things to do with my life than engage in politics, so I abandoned that one and moved on with my life.

all the other build system things, like for MK_FOO are lower case only. I worry this would cause confusion...

So you can't allocate pages for code read only... you've got to write to them sometime and there's no interface to change the mapping.

This should be fine.

seems good, but didn't pedantically check all the options.

Apart from the comment I don't understand, this is good, I think.

In D58357#1338418, @des wrote:

In D58357#1338417, @imp wrote:

Why bother?

It's causing a build failure downstream.

Sure, if it works and we're on a good path to removing Giant (or if it's already gone, I've not looked).

Why bother?

In D58262#1336336, @ngie wrote:

Side thought: it would be nice if these were actually broken down into subpackages, e.g., indent-tests, etc.

jhb's changes

In D56474#1335651, @khorben wrote:

No longer build bomtool(1) and spdxtool(1) with NO_SHARED in the tooling phase. (Reported by imp@, thanks!)

how is this related to the pkgbaseify that was linked off a foundation blog?
The code looks clean, but I don't know if it's correct.

I like it.