I think this is good and agree it should be easy to carry as a local patch while coordinating upstreaming. Man page update needed too though.

Upgrading the build host is a way of saying that building images for a given version is only supported if the build host is running the version of the image you're trying to build.

Approved

I thought that was planned for 12, actually.

This is fine with me, and I have no objection to it going into FreeBSD first and @dim@ or @markj or me working on upstream.

In fairness, this example pre-dates the crypt_r in FreeBSD by 4+ years.

@linimon I removed the "libelf" prefix; this review includes a change to libelf (which is actually the dependency D10487 and ought not be included here) but this change is not a "libelf" change.

In D16385#351802, @alc wrote:

If the switch to lld on i386 is changing the default image base, then we might as well be changing it to a superpage-aligned address.

Businesses may have early NDA access to microcode that the port does not have access to or cannot distribute.

In D16370#351674, @markj wrote:

We'd re-apply the old blob. I'm not sure if this is a bug or not - if no blob is loaded at boot time, then upon resume the new update will be lost anyway.

Undo renames pointed out by @cem

Awaiting review; I pointed out a couple of minor nits to address on commit

Other issue in D10487

The commit message should have background about the removal and why we believe it's acceptable (did not actually work, hardware has not been produced for years and has no known users, etc.)

I pinged @kaiw by email requesting a look at this change.

I still believe this change should go in, although if we really believe it's a backwards compatibility issue perhaps avoid default only with -n -n or -nn?

atombios.h is 3rd party code, although I am unsure if there's a viable upstream to submit it to. Please go ahead with the others for now though.

Ping

Approved, we can get additional testing with it in tree.

LGTM with @jkoshy_users.sourceforge.net's comments addressed

@bcr please go ahead

Ping

What happened to this change?

I think this is fine.

Googling turned up http://sunxi.montjoie.ovh/ with Linux status, which claims:

FreeBSD version number bumped in rS337009

I dislike the magic 2 without a comment or #define

In D16528#351019, @kevans wrote:

force a bootstrap LLD to be built?

It's possible to build makefs FAT support now:

1. apply D16526 (header modifications)
2. copy msdosfs_fat.c and msdosfs_lookup.c from sys/fs/msdosfs to usr.sbin/makefs/msdos
3. apply D16438

Updated patch that shares kernel headers, based on part of D11197

Phabricator's still working:

Still Importing...
This commit is still importing. Changes will be visible once the import finishes.

The hacky workaround would have to be something like #define gets(s) abort(), NULL instead, but I am unable to verify the gets -> __gets_chk transformation works in the first place. Maybe the GCC build does not enable this on FreeBSD?

Little tip, if you use just the short D##### tag Phabricator will automatically add links both ways:

• D16337 for build options etc
• D16336 for changes to stand/
• D16335 for libve
• D16334 for libbearssl

Seems a good change overall, thank you

• Exclude buf.h changes
• Rebase on newly copied sys/fs/msdosfs files

I would prefer that we share the common files, and have the side effect of allowing us to more easily test and debug the msdosfs code, but in the interest of expediency I've posted a rebased version of Siva's work that copies the files to userland -- D16438. We can take a careful look at deduplication later on.

I committed my change in rS336691; if we're going to make a change like the one in this D11962 we can include lib/clang/include/llvm/Config/config.h as well.

I have a related change for Clang in https://github.com/emaste/freebsd/commit/b03c6b060658f5fed4a2ad8511095c5f4df6e9f4 to avoid rebuilding so much when __FreeBSD_version gets bumped.