Have more to review.

yea, go ahead and commit this. I'd rather we fix lua to generate the right thing, but that's a few days away.

Needs some work still... Likely will need another pass to make sure it all lines up.

lgtm, though I must admit to review fatigue

So style(9) requires a blank line at the start of a function with no local variables. I tagged a couple, but there are more.

this looks fine, apart maybe from the copyright stuff...

This looks good to my eye

I'm inclined to hold off a little on this one still... If I made the changes in other reviews, as seems likely, then we can revisit. This will give you time as well. I wonder why we've not hit this with the external toolchain work that's gone on until now.
So let's let this one cook a while longer and clear out other patches while it does.

Ding! We're ready to roll on this one.

• We don't support gcc < 4.2.1, so varargs.h now is just #error

sparc and powerpc too

buildworld mips64 and mipsel completes w/o error

I'll note that phk suggests that mips can't use this file in his initial commit, but I see no reason why it can't.

One last nit, and then I think we're good to go.

In D14248#300057, @arichardson wrote:

In D14248#298772, @imp wrote:

A better read on 'why' they aren't defined would be good to know. Is this a freebsd specific extension to our clang? Are other architectures affected?

As far as I can tell the FreeBSD clang install does not include the stddef.h, stdarg.h, etc from the clang sources but instead uses the files in /usr/include.
I am building clang using the CMakeLists.txt from LLVM so it installs those files.
The clang builtin headers already define these macros and in some (most?) cases are included before the machine/stdarg.h header so we get macro redefined warnings (-Werror) here.

In D14295#299963, @emaste wrote:

I presume the commit will have Sponsored bys for Google Summer of Code, Netflix, and the FreeBSD Foundation; any others?

this time include all revs

Fix reviews so far, plus add color.lua

seems legit. Though if you make them STATIC you shouldn't need to also initialize them to NULL because that's automatic.

this is fine to go in, but it might make sense how it can be more table driven (both for the install lines and the PLIST generation).

Moved to /boot/lua

Looks good to me.

Only 7 more commits to this logic, and it might be right.

In D14261#299111, @mav wrote:

Yes, I had that concern about memory allocation too. I agree that allocation code should be rewritten to not require more continuous pages then required by hardware. But actually present setting of the MAXPHYS and MPR_REQ_FRAMES easily fit into your proposed 2MB/16384 threshold. What would you say about committing this patch with MPR_CHAIN_FRAMES set to some limit sufficient for default configuration like 16384, just to protect against somebody who may have increased MAXPHYS until the allocation is fixed?

I think we're not there yet...

A better read on 'why' they aren't defined would be good to know. Is this a freebsd specific extension to our clang? Are other architectures affected?

Turns out IEEE 1275 standard and successors all guarantee that text strings are 1 to 31 characters followed by a NUL byte, so my worry is bogus.

So I have a memory of OF properties not being NUL terminated. If so, this code is wrong, though it might accidentally be right in some cases.

I went to add comments to both these locations about why we do odd things with them, and found myself just pulling in the commit to the main tree in r328975. So this review might close automatically.

I have a few of these that conflict a little, but go ahead and commit these and I'll sort that all out.

Looks good to me. Thanks for splitting it out. There's no huge rush, so I'd make sure that bdrewery signs off as well.

Overlooked emaste's comment suggestion, which I like...

One minor quibble.

env LC_ALL=C sort, for great justice

I'm a little uneasy about un-forking, but we're past the craziness of the past so maybe it's OK so I'll approve it.