put nullability macro outside kernel ifdefs

This revision successfully builds and reboots, so I think it's right But since it's systm.h and we do some funky monkey business in there, I'd like more eyes on it to be sure.

rebase, again

rebase

Rebase (again!)

Rebase

Nice.

btw, the rest of the changes look totally fine. Sorry to be so nitpicky over this one...

This review is missing a lot of files (even prior versions). rtsx.c at the very least is missing
Does this driver support MMCCAM?

Non pmc bits look good to go

Will this screw up the tracebacks? One of the reason that I've compiled at lower O levels is to not have @#^#$Y up DEBUG kernels...

In D26448#588627, @mjg wrote:

Given this already has support for reusing items from a global list, why uma allocation in the first place? Most notably why per-CPU caches. The current code does not scale regardless and is expensive to use, but with expected low msg rates it should be fine for the time being.

Another round of comment cleanup to make things more descriptive and less verbose.

Update some comments.

Fold in feedback from MarkJ

Why do we install libgcc_s multiple times?

In D26450#588410, @zeising wrote:

You probably want to remove tools/build/options/WITHOUT_APM since that option is gone and update tools/build/options/WITHOUT_ACPI to indicate that it also governs the installation of the apm(8) userland utility. OptionalObsoleteFiles.inc probably need to take this into account also.

In D26220#588231, @jmg wrote:

In D26220#587460, @pnagato_protonmail.com wrote:

@jmg @imp I have seen other places where KASSERT was re-defined as

#define	KASSERT(exp,msg) assert((exp))

I think using assert should be used. It doesn't pollute stdout, generates a core dump, and is more obvious that there was a failure.

Thanks.

Fix comment and silly lack of assignment. Tiny style tweaks too.

In D26428#588030, @1983-01-06_gmx.net wrote:

You description is wrong. No BIOS will boot off an EFI partition. Don't mix BIOS and UEFI firmware implementation.

Add comment documenting why we only conditionally install bootx64.efi

Looks good to me. I'd be tempted to commit the kernel and non-kernel parts separately since the kernel bits aren't directly related to the firmware downloading change, but merely facilitate it (and possibly other) uses.

I think this is fine

In D26340#587230, @gallatin wrote:

Is there a file which is already perfectly style(9) compliant? Is it this file?

Assuming a "perfect" file, we could then tweak the clang-format config iteratively, until we find the output which has the smallest diff, and then tweak clang-format to fix the remainder and bring the diff to 0.

I think this is good. There's many other strings we might consider for the reset, but this is good.

I'm happy now. Thanks for listening to my feedback.

Minor nit, which could report a bad write total in some rare circumstances is the only issue I see.