I'm looking for feedback on this approach.

In D34125#776217, @jrm wrote:

In D34125#776098, @brooks wrote:

In D34125#775977, @jrm wrote:

@brooks The calls to elfctl are happening in post-build, but I don't think it is straightforward to both 1. set the feature flags on the binaries under the build-tree and 2. have these binaries installed to ${STAGEDIR}.

So either you need to change things so paths are relative to ${BUILD_WRKSRC} or revert to the previous case of doing this post-install. Once flags are applied to the build binaries stage should install them, but the result is a bit ugly. Maybe my suggestion wasn't good and we should wait to see if there is a need to run elfctl on things in BUILD_WRKSRC in practice.

I had already tried doing things post-build and pointing elfctl to the binaries under ${BUILD_WRKSRC}. The outcome is often that the binaries in ${BUILD_WRKSRC} are updated, but not those under ${STAGEDIR}. This is because binaries are often staged at the end of the build stage. In other words, post-build and post-install make no difference, so I think we are unfortunately forced to point elfctl to the staged binaries. I'll spend some more time to be certain that it is indeed difficult to modify the binaries under ${BUILD_SRC}, but also have these modified binaries staged.

In D34125#775977, @jrm wrote:

@brooks The calls to elfctl are happening in post-build, but I don't think it is straightforward to both 1. set the feature flags on the binaries under the build-tree and 2. have these binaries installed to ${STAGEDIR}.

For general infrastructure, I think you want it to be post-build not post-install because test targets may run on the build tree binary.

This is a step in the right direction.

I wonder if setting MK_BOOT=no in Makefile.libcompat where we set MK_TESTS=no would work and be cleaner?

The de4led driver only works with BERI and special bluespec. MTL supports a rather clunky touch screen.

Right now I've got:

Seems fine. I think this will (eventually) let me remove some hacks from LLVM ports.

Looks good in general.

I wonder if these want a trap or exit handler

The k in kvaddr_t is like the k in kinfo.

In D33886#766268, @jhb wrote:

In D33886#766258, @brooks wrote:

I think this might break powerpc which has COMPAT_FREEBSD4 in GENERIC (why?).

But it shouldn't have any references to the type. Only the freebsd4_sendsig references this. grep doesn't turn up any references

I think this might break powerpc which has COMPAT_FREEBSD4 in GENERIC (why?).

I think this is right.

Remove needless cast

In D33780#764080, @andrew wrote:

Do you plan to also update other architectures and ABIs?

• Update amd64 and arm

It seems like with pkgbase you want some sort of magic packages or re-rooted pkg repo support so you can get them from the specific target's pkg repo, but that's for another day.

Does there need to be a set of ObsoleteFiles entries?

This seems viable, but I wonder where we envision the sysroots coming from and if it impacts the location?

I've got a similar patch

Go ahead and remove it. We're not using that platform (Terasic DE4) except for MIPS and MIPS is gone (🎉).

In D32498#756273, @imp wrote:

I had to back out the automatic testing because this is built at a time we have no libraries yet, so test-includes.c can't create a binary.
A number of options are possible, and I'll ponder them over the coming days.
My universe, which wasn't completely clean (since I use meta mode) didn't catch this possible issue.

It's also not adapted to a modern METALOG-based setup which would preserve permissions correctly and allow NO_ROOT builds. There are many other options for additive image constructions including tools/tools/makeroot.

As a downstream consumer with many changes to various config/files* files I'm fine with a break, but would very much like to avoid having more than one round of large-scale changes. @manu's re-sorting of files.amd64 required completely reimplementing our changes as git had not hope of figuring out what to do. I assume the same will be true of other downstreams. If we did go to UCL it might be worth renaming the files (e.g., files-arm64.ucl)

Right now it's never a dependency. In some ways it would be nice if it was and we could stop committing generated files, but it's potential confusing if we don't have syscalls.h and sysproto.h in the tree.

This seems fine as is or could adjust per on the conversion on adding syncalls.conf for the default ABI.

Looks good. Thank you!

Thanks for working on a separate syscall.

In D33224#751117, @manu wrote:

Also I'm not a fan of the automatic conversion.
I've put some work to sort files.arm64 a while ago and now it's a mess.
For example all coresight files are correctly grouped right now but this change put them in different part because some are standard, some for fdt and some for acpi.