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.

In D26369#586493, @andrew wrote:

Only support aout.c on i386 & amd64

One of the big advantages of style(9) has always been it's been a range of acceptable behavior. As we've loosed the strict dogma over the years, it provided a large enough space that people stopped fighting over style issues... Going to a strict, at checkin time, thing would a huge step backwards. clang-format fixes a few issues, but still causes far more issues than it fixes. It's OK if someone wants to run it on their code that has a radically different format, but for things that are close, I don't see the value.

meh, not a very good job. I see only one actual formatting bug in all these changes, though the headers are arguably slightly better modulo the double inclusion.

In D26044#585469, @arichardson wrote:

In D26044#578026, @imp wrote:

Probably closer to ~2000 for the cut-over date. Toolchains in the 90s did support indexing, but I ran into several cases where lorder helped even though it shouldn't have... That did stop being the case sometime in the early 2000s, though... At least for static libraries. Dynamic ones did indeed work from about the mid 1990's w/o ranlib/tsort/lorder. Linux's a.out libraries being the last one I recall where that was beneficial.

The main risk here is that it reorders all the .o's and may cause too long of a call/jump that didn't happen before... Not a case I think we need to seriously worry about, but the possibility reinforces the notion of a universe before this commit.

Quibbles aside, i like this. There's a minor downside to the ARFLAGS change, but not enough of one to worry about. It will increase disk usage in builds a bit, but only in edge cases. The clarity and simplicity of the resulting use more than make up for some folks with extremely old code-bases that might have to adjust, or those that have added it by hand to their make files. This risk suggests an exprun might be warranted.

I think this is unlikely to break anything other than duplicated sources so I was planning to commit it on Monday. @imp is this okay or should I ask for an exprun?

In D26284#584505, @jhb wrote:

I'd rather axe device_busy and instead require drivers to use device_quiesce.

However, this does mean that bus drivers need to use a bus_generic_quiesce that recurses to preserve the "device_busy of the parent" semantic.

In D26302#584633, @ian wrote:

So, what prevents "kldunload icee" while someone has the cdev open?

This looks fine to me.

In D26220#584195, @pnagato_protonmail.com wrote:

@jmg @imp Need your input how to proceed on the sbuf_negative test.

Fixed in r361015

Kill it with fire

badsys is a piece of work...