Only the uncontested parts of this were committed. I'll open a new review for my solution to the Ingenic JZ ports. I'll monitor this review for further comments on the mips4k retirement that was objected to. The Ralink is easy to keep (assuming that I work out the atomic issue), but the AR53xx removal was motivated also by the fact that it's disconnected from the build at the moment and there's no config files and other infrastructure present to build it. That has to be fixed before we can retain that.

In D18578#396786, @miwi wrote:

@asomers I agree for splitting it up for the commit, but for now i'd like to keep it in a single patch due to easier to test :).

This review is too large to effectively review. the control programs should be a separate review. I'm not sure that every single etc.init.d thing needs to be reviewed, though the make infrastructure needs it.,
Also, there's a lot of 'copy the whole file' stuff, for example devd.conf, which is simply not going to work. In a review this huge, it's impossible to really have a good discussion about that.

In D18543#396137, @br wrote:

X1000 is a single-core IoT cpu released 3 years ago. X1000/E even newer. They are so nice, I bought 20 of them (only 5 USD each).
Since X1000 uses parts from jz4780, may be it is better to rename jz4780 to X1000 and remove SMP support.

In D18543#396125, @mizhka_gmail.com wrote:

I prefer to deprecate chips / sub-arch, but not removal. Honestly approach with "unimplementable" atomic_64_swap looks too aggressive.
I and @yamori813_yahoo.co.jp have boards with mips4k SoCs and to be honest such chips do their job well.
Another point: I saw plenty of emails with information that 8Mb is very slow. If it looks small for certain group of people, it doesn't mean that it's small in wide audience. I see that firmware with kernel, modules, 20Mb of uncompressed UFS/CD9660 filesystem is powerful to handle plenty of tasks: routing, monitoring of sensors, graphical output to LCD, keyboard/IR control and so on.

Also I see that many people & companies (at least in Russia and Japan) use devices with mips4k/24k chips. Seriously, world still use 802.11a/g for wireless access and they are happy.
I would ask to deprecate chips if atomic_64_swap is "unimplementable" for them, rather than removal.

I think this is about as good as a review this size gets :).
I'd be happier if nwhitehorn OK's it before you commit.

This matches what I puzzled out the right fix should be, and is a bit better than what I had in mind before this problem slipped away...

Sure, any number here is better than 0. 60 or 300. I don't care.

lgtm now

int ret; rather than uint*_t ret;

looking better. Next round of suggestions shouldn't be so bad.

Netflix doesn't use efi_system_reset() in our version of FreeBSD. Changing the signature is likely fine.

OK. That's all I have time for tonight. Should be enough to keep you going. Gotta go get some sleep.

This changes does what it says, but no clue why we need it.

In D18455#393317, @cem wrote:

LGTM. I still find the 'mirror' name confusing, but maybe that's a personal problem ;-).

updates per cem@

Update the pacing base that Kirk sent me to cope better with multiple workers.

I looked at this on my phone a few days ago and meant to stamp it with LGTM when I got back to my computer, but that fell through the cracks.

The code seems fine, other than the weird msi_tupelo which randomly seems to be the same as msi_enabled, but only some of the time. A comment is needed to explain why the oddity.

I'll do the ones I marked and call it good and do round 2 for the const changes and the dlopen feature.

I've updated to be close to the end game. All that remains is readdir(/libexec/nvmecontrol and /usr/local/libexec/nvmecontrol) for all the .so's at startup and we'll be to the point where Netflix can deploy the Sekret Soss modules we have from Vendor X w/o changing base or polluting base with NDA material.

Lots of cleanup, will be separate commits

Thanks for the feedback. I'll see how much I can include in my next round as some of them are asking for more structural changes beyond the scope of this set of changes (the suggestions are good, btw, just am keen to avoid too much scope creep).

There's a suggestion that the new trim program be named 'discard' to match linux's discard option on mount. Perhaps discard would be a better name. Though I hesitate to make such a bike-sheddy suggestion.

tweaks